ABM Case Study Enterprise Architecture Stream
Dec11

ABM Case Study Enterprise Architecture Stream

SEAS consulting team has completed  Situation Analysis (SA) with 51 clarified concerns related to ABM case study. The teams has identified multiple problems in the current ABM business which are related to people, process, information and technology areas. An Enterprise Architecture stream has been setup to take responsibility for  further in depth analysis from EA perspective and in this regard EA stream has selected TOGAF  9.1 as a framework to develop architectural artifacts. The issues faced by ABM currently are mostly related to the overall operating mechanism, structure of the organization and IT automation of the business. Following are the problems explained in details from EA perspective: ABM Operating Mechanism: ABM has some major issues related to business processes being followed by its departments. In many departments processes are executed on an ad-hoc basis, this is due to the fact that none of the processes have been documented and no availability of Standard Operating Procedures SOP for any department. For architects, this element is one of the major issues due to which ABM is not able to sustain its operation and is the main cause of disconnect between different business functions. Organization Structure: Even though ABM organization structure has the core departments to run the business but these departments are also performing support functions as well. Functions like Project Management, Demand Management, Innovation Management e.t.c ideally should be separate departments to provide support related inputs functions mentioned. Architects believe that the current organization structure needs revamp by introducing new business units to increase the overall efficiency ABM operation. IT Automation: Another area of high concern for architects is the use of technology to support business functions. After having a session with the board, it was highlighted that ABM is mostly using excel sheets to support their activities such as , sales forecasting ,production schedules, customer management and product cataloguing. On the other hand there is only one known IT system being used by Finance and that is Oracle Financials. From EA perspective, IT is core enabler for business’s smooth and sustainable operation. In the light of above issues , it is understood that the reason of not having crucial information available to the right stakeholder is due to the lack of business process automation and for the automation, business processes have to be documented and owned by the rightful owner. The approach which EA stream has defined , utilizes the TOGAF 9.1 Architecture Development Method ADM. There are multiple artifacts which are required to ensure a proper development of the architecture but for the problem on hand, EA stream has identified list of artifacts from ADM and will be...

Read More
ABM Case Study Situational Analysis Update
Dec09

ABM Case Study Situational Analysis Update

The SEAS’ Consulting team participating in the ABM Health Check Engagement Simulation completed its Situation Analysis phase.  The team worked diligently across the three streams of Strategy & Innovation, Enterprise Architecture, and Change Management to examine, analyze, collate, and document its findings. The team used Kepner-Tregoe’s Situation Analysis (SA) method to complete the analysis of all issues and enumerated 53 major issues which translated into 73 clarified concerns.  The 73 concerns were further rationalized (eliminating redundancies and consolidating issues with single action to resolve) into 51 specific and prioritized concerns classified by priority, importance, & growth.  Each of the individual streams: Innovation & Strategy, Enterprise Architecture, and Change Management were pegged against these 51 concerns specifying which stream, or practice, leads the resolution of the concern and which streams, or practices, receive the analysis to complete its downstream work. As an example, one of the 51 specific concerns was: “Production Schedules/Forecasts are not used during sales cycle for new commitments.” This concern was prioritized as Seriousness (H), Urgency (H), Growth Trend (Increasing).  It was then assigned to  Business Architecture (EA) to lead its resolution.  The output of this effort will feed the Change Management team to work on the People aspect of resolving this concern such as Training & Communication.  Finally Technology Architecture (EA) will be the recipient of the output from Business Architecture & Change Management team to define the target Architecture for addressing this concern. In the coming few weeks the three streams will complete their analysis of the top concerns and develop the associated roadmaps.  Once that phase completes the consulting team will work on consolidating the deliverables into one body of work that rationalizes the analysis and proposes one roadmap as an output of the Health Check engagement. The consulting team will be posting their individual updates in the coming week to share with the society their findings and experience thus far with the case study. Stay tuned for progress as we continue our journey in solving ABM’s Business...

Read More
Leveraging Enterprise Architecture in Enterprise Risk Management
Nov21

Leveraging Enterprise Architecture in Enterprise Risk Management

Enterprise risk management (ERM) is one area that I believe EAs could positively contribute to. Several years back, a manager in charge of ERM approached me enquiring how EA could benefit his department. He knew what EA was and was keen to see if he could benefit from it. His primary challenge was assessing impact of risk across the enterprise; his team was handicapped, as they did not have traceability capability. In this article, I explain how EA helped him achieve his objectives. Organizations deal with different types of risks that, if not attended to, could have adverse impact on organization performance and outcomes. Generally speaking, “risk” is the potential of undesirable outcome resulting from a given action or omission (foreseen or unforeseen). On a different note, “risk management” (RM) is the identification, assessment, and prioritization of risks followed by appropriate actions to minimize, monitor, and control the risk impact. The intention of this blog is not to explore risk management as such but rather explain how enterprise architecture (EA) could benefit risk management. Those of you seeking more details about risk management can explore other external sources. While I do not dispute that RM is not unique to EA, it is important we appreciate that EA has great potential to contribute to GRC (governance, risk and compliance) by feeding into the enterprise risks management (ERM) process. The problem with traditional RM efforts like program and project (risk management) that are usually independent, narrowly focused and functionally driven is that they work in silo and fail to integrate at enterprise level leading to fragmented view of risks each with its own classification, criteria, and measure. Ultimately, most critical risks with major business impact never make it at the enterprise level though the resulting consequences do. So what is the rationale behind leveraging EA in ERM? As we all know, EA involves blueprinting an enterprise by connecting the business, information, application, and technology layers. Usually, we achieve this iteratively through an architecture development method like TOGAF. Whenever we create (or update) and link each of these architectural layers, we get the opportunity to assess impact of change on subsequent layers. The presence of this unique traceability creates a window of opportunity for ERM. If we extend the concept further, it could help organizations identify and assess impact of risk on these architectural layers (I like to view this as enterprise assets). Why do I say so? One of the toughest challenge in ERM is modeling risk and its impact on enterprise assets. Techniques like fault tree and event tree analysis have been used to model risks before but unfortunately, they are ineffective when...

Read More
Impact of Disruptive Forces on Enterprise Architecture
Nov15

Impact of Disruptive Forces on Enterprise Architecture

Traditionally, the focus of Enterprise Architecture (EA) has always been a combination of both business and technology architectures. In the near future, this focus will gradually shift to business design or as many of us term it business transformation. This shift entails providing existing architectural as well as new advisory services to the enterprise. EAs will not only limit their advisory services to traditional enterprise architecture domains (business, information, application, technology) but rather will engage further in driving change along strategy, market, product / services and capabilities. Below are some of the key trends we are witnessing right now: Disruptive forces like social media and mobility have major impact on enterprises Unlike before, changes to business operating models is more frequent now The shelf-life of business architecture models and artifacts is shrinking fast Understanding capabilities is central to managing impact of disruptions Unlike before, enterprise architects will increasingly focus on business design A new architecture role focusing on business design is slowly emerging Disruptive forces like social, mobility, big data, cloud, gamification etc. typically have the following characteristics: they bring along innovation, they open up new markets, and finally expose new value networks. These combined characteristics of disruptive forces eventually displace earlier offerings and technology from the existing market place. Typically, we should view disruption as a force that rips through an existing market by creating a new market altogether. Apparently, most disruptive forces tend to be “digital” or “technical” in nature mainly because they accelerate disruption by providing new and faster access channels that empower consumers and improve market penetration. In the early days, we used to believe “differentiation” alone creates a competitive advantage for enterprises. While competitive advantage may have been good enough in those early days, it is no longer adequate for enterprise that wish to dominate a market place by creating uncontested markets and making competition irrelevant. Unfortunately, differentiation on its own does not cause “disruption”. In essence, you would need a combination of both differentiation and low cost to emerge as a dominating force. In fact, to be successful, you would need to sustain the state of dominance. If you explore most existing EA practices, you will notice the focus has been blueprinting enterprise at people, process and technology layers. Unfortunately, disruption does not only occur in this layer. Typically, disruption occurs at a much higher or contextual layer where we define business operating models or as most of us term it target operating model (TOM). Very few EAs have attempted to include in their scope business motivation (strategy) and business value (value chains and networks) layers.  The absence of these layers in their...

Read More
Decision Support Enterprise Architecture
Nov11

Decision Support Enterprise Architecture

 Enterprise Architecture is a framework of decision making through its models/view which are the integral part of EA discipline. The EA models/views should be relevant to the management deicions making needs and thus they should be designed based on the suitable metamodels. These metamodels, in turn need to be properly and continuously maintained. While there exits several methods for the metamodel development and matinetanance, these typically focus on internal metamodel qualities and model engineering processes, rather than on the actual decision making needs and their impact on the metamodels used. These metamodels, in turn need to be properly and continuously maintained. While there exists several methods for the metamodel development and matinetanance, these typically focus on internal metamodel qualities and model engineering processes, rather than on the actual decision making needs and their impact on the metamodels used. From previous many years, Enterprise Architecture (EA) has grown into an established approach for management of information systems in enterprises. EA is a model-based in the sense that diagrammatic descriptions of the systems and their environment, constitute the core of the approach. The purpose of EA models/views is to increase the general understanding of an organization’s business along with its information system landscape, the objective is to make corporate decision making easy and responsive. The backbone of any EA model is its metamodel, the design and structure of this metamodel greatly affects the way organization prepare its decision reports. The metamodel has to be interoperable and traceable, to get the optimum value out of it. There are few popular frameworks which propose a metamodel of their own e.g Defence Framework(DoDAF) and MODAF, while some have focus on development and maintenance processes which can be applicable to many metamodels such as FEA and TOGAF. In any case, regardless of implicit or explicit frameworks, metamodels play an important role in overall EA efforts. For any EA model to gain success, the metamodel for it must support decision making for the business and IT of the organization. An overly done metamodel will complicate its maintenance and very simplistic metamodel will kill the purpose of EA. A middle approach is required when designing, so that it fits the purpose for the organization. To keep a metamodel align with business needs, the information prescribed by the metamodel must be relevant to management decision. Business expects a tangible value from the EA effort and  business , to some extent is interested in how there organization is operating holistically and in integrated form but what they are mostly interested in is, what decisions they should make to enhance the productivity of the operating structure. Some of the crucial areas...

Read More
Building Strategic Process Architecture
Nov05

Building Strategic Process Architecture

Now a days companies are developing Process Architecture (PA) under the overall umbrella of organization’s Enterprise Architecture initiative. PA is an important architectural element for any organization which has to be done with proper planning and followed by strong methodologies. But before doing that what do we actually mean by the PA, what is its definition and how does it actually helps organizations in their decision making, be it strategic or tactical. There are many definitions for PA and each of them different perspective addressed: 1. The architecture of the business processes of an enterprise is defined as the type of processes it contains and the relationships among them . [Barrow 2007] 2. Process architecture is the picture that says what process types there are in the organization and what there dynamic relationships are: a network of instance at work, all operating at the same time, some activating others and some interacting [Ould 2005] 3. Process architecture is a methodology for identifying and aligning and organization’s key business processes against business requirements and to determine how to organize and implement formal process management [performance Design lab 2011] 4. Process architecture is a schematic that shows the ways in which the business processes of an enterprise are grouped ad inter-lined [Frolov, et al.2009] 5. Process architecture is the structural design of the general process systems and applies fields such as computers (software, hardware, networks etc.) business processes (enterprise architecture, policy and procedures, logistics, project management and any other process system of varying degrees of complexity [Dawis, et al, 2001]   The above definitions though proposed by different thought leaders but each of them is targeting mix of business areas. Although none is wrong but it doesn’t show unique form which can be used as baseline definition for PA. For me PA , it has to have all the aspects of process design to make PA genuinely a value added architectural block for EA. So this is how I see it ” PA is an architecture building block consisting of (people, process, information and technology) PPIT in an integrative arrangement, defined through strategic and tactical relationships between  PPIT “ Having said that PA has its AS-IS and TO-BE state, both are to be developed from organizations strategic and tactical direction’s perspective. There has to be two main objectives of the PA development for organizations: a)      To satisfy customers demands b)      To achieve more efficient processing A sound and consistent strategic PA has following attributes which must be inline and should be defined in structural manner 1. Business Events: All the business events which are occurring for current state or which may occur in anticipated future, should be...

Read More