ARIS defines IS Functions (Capability in ARIS 7.1) as a generic IT resource that supports a function within a process. (I truly love the way IDS has defined this tricky aspect, which many manager in IT are not able to capture immediately).
For example, if we consider an application such as Microsoft EPM Project server, which support “Project Management” capability.
However, Project Management function capability is at a higher solution level, and it is more interesting to identify the activities/components of the Project Management process such as resource management, Project execution, Project risk management and so on.
It would also be interesting to identify what features of the just mentioned activities EPM supports. For example, features of the activity “Resource Management” such as Time sheeting, allocation of resources, Management of resource information, assignment of resources, Effort tracking and so on. I would recommend a breakdown of capabilities to this level of detail is needed for any decent level of architecture analysis.
Level 3 (Features level): Time sheeting, allocation of resources,,,,
Note that there can be a need to breakdown the level of details into further details, level 4 in this case. By this hierarchical approach, link IT applications and their capabilities. The level of detail of the capabilities can be captured in an attribute.
I have a theory. When I propose a solution, and if someone poses a question on that solution for which I do not have an answer, I deem my solution as flawed.
I am in-charge of defining and deploying IAF using ARIS in the organization I work for. A question was posed to me, as to why "Business service" and "Business information service" use different objects when both represent the service notion of same business activity, but from different aspects. In fact "BS" and its partner "BIS" also have a one to one mapping.
BS captures all aspects from the business perspective and BIS filters the same purely to an information aspect.
From an ARIS modeling point of view, I find it best to reuse the same object to capture BS and its BIS but to use different views (model type) to capture the relevant aspect's artifacts.
For example, service object name "Hunt rabbits" in model type Business service interaction model, captures interaction with other business services such as “sell rabbits” and “cut rabbits”, with inputs such as firearm, transports, roles such as hunter, butcher, vendor and so on. The same service object “Hunt rabbits", in the model type “Business information service interaction model” captures the information aspects of hunting rabbits such as season, hunter skill level, market price of rabbit meat and so on.
I notice in many situations that physical hardware infrastructure artifacts are mixed with and the IS/IT aspect architecture views. I agree with the need in some situations where there is an interest to know the actual instance of the infrastructure such as a server. But for large architecture overview models, mixing aspect areas is not a good idea as it posses governance issues and overkill of information with too many objects scattered on the model.
This is similar to differentiating the aspects of IS/IT and infrastructure in IAF.
In IS/IT architecture overview model (IAF’s IS/IT logical and physical components), architects are more interested in interactions between various IS/IT components and not the infrastructure which supports it. Usually, the lead IT/Solution architect will be the owner of this view.
A technology infrastructure topology model captures the TI component’s interactions and where they are located. The infrastructure folks would be the governor of this view.
There should be a cross reference between the 2 aspect areas, to capture the links between an application and infrastructure supporting them. Use of contracts is very critical to understand dependencies.
I find that this solution of having an aspect area centric modeling by the differentiating the aspect concerns eases the clustering of models and also solving the tricky issue of model governance.
When I started to write a report in ARIS, I did not have the "Hello World" to help me out. So here is something you will need to launch ARIS report scripting.
function main()
{
var g_nloc = Context.getSelectedLanguage();
// *******************
var oobjects = ArisData.getSelectedObjDefs();
var oSourceModels = ArisData.getSelectedModels();
var odataBases = ArisData.getSelectedDatabases();
After much thought on the value delivery of IAF, there 2 critical points I wish to state.
·Too costly to deploy. Needs a lot of training and not business friendly. This increases resistance and thus cost of deployment.
·Absence of a development method for the contextual abstraction layer. I guess this is where consulting comes into play. Again, a cost going back to point 1.
However on the plus, I would like to mention again 2 key points
·Finally there is light in a world of IS where there is total darkness
·Your best short towards business-IT alignment
My EA folks can argue other pros and cons, but I would love to argue how I could round up their arguments to be aligned with mine.
After working for a while at an organization someone asked, what is it that I do? And I had no answer. After some research, Eureka! "Enterprise architecture methodologist'
The complexity of EA necessitates that a trained method engineer in Enterprise architecture modeling and methodology techniques, instruct the EA practice to managers and architects, and in situations conduct the EA it self, through iterative interviews. Using a methodologist such as me, provides an experienced knowledge base from which ideas and suggestions on overall improvements can be obtained.
EA requires high buy-in due to many inhibitors. The EA manager has a highly important task to promote and sell this initiative to the organization. An important aspect for this task is “Change Management (People)” is very important to handle the high buy-in required by Enterprise Architecture modeling initiative. Kotter’s "Winning at Change" Leader to Leader, proposes a 8 step strategy which can be adopted to successfully handling change. Its relevance to EA is evident.
·Establish a Sense of Urgency
1.Examine current realities and position of the Enterprise Modeling initiative, using the performance measurement system created.
2.Identify and discuss inhibitors, potential inhibitors, or major opportunities for Enterprise Architecture
·Form a Powerful Guiding Coalition
1.Assemble a steering group with enough power to lead the change effort.
·Create a Vision
1.Create a vision to help direct the change effort
2.Develop strategies for achieving that
·Communicate the Vision
1.Use every vehicle possible to communicate the new vision and strategies.
2.Empower Others to Act on the Vision
3.Handle obstacles and inhibitors to the change
4.Encourage employees to accept the change
·Plan for and Create Short-Term Wins
1.Plan and target for visible and incremental short term performance improvements.
2.Recognize and reward for such improvements
·Consolidate Improvements and Produce Still More Change
1.Reinvigorate the process with new initiative by increasing scope of the modeling initiative.
·Institutionalize the change
1.Change needs to become institutionalized and has been widely accepted as part of the organizational culture, if not it can be subject to degradation. Hence efforts are required to anchor the change into the organizational culture.
Architects often need to perform analysis on a set of IT Applications for redundancy and gaps in the functionality it offers. This activity is required for example during
Application convergence
Redundant Application phase-out
Activity 1: Contextual Analysis (IAF's contextual analysis, TOGAF's Preliminary Phase: Framework and Principles (Re-look) and Architecture Vision Phase)
When conducting any architecture analysis, it is recommended to conduct a contextual analysis of the architecture so that the objectives are agreed upon. This is a collaborative effort which requires proper buy-in from all sponsors. Note that the risk of failure is high if this step is skipped. Also the effectiveness of this critical step depends on the maturity and capability of the EA practice within the organization. The common denominator of all enterprise architecture wisdom is: start simple, remain simple but grow (mature). This is very true in this stage. Based on TOGAF and my own experience the following needs to be exchanged and validated by all stakeholders of the architecture.
·To review the organizational context for conducting architecture analysis
·To identify the sponsor stakeholder(s) and other major stakeholders impacted by the business directive to create the architecture analysis
·To ensure that everyone who will be involved in, or benefit from, this approach is committed to the success of the architectural process
·To define the "architecture footprint" - the people responsible for performing architecture work, where they are located, and their responsibilities
·To define the framework and detailed methodology that are going to be used to develop the architecture and share it across
·To confirm a governance
·To define the architecture principles that will form part of the constraints on the architecture work
Activity 2: Application modeling
(IAF's Physical IS/IT, TOGAF's Phase C: Information Systems Architectures)
Most of the situations, architects a-priori know what applications need to be analyzed. But before making a rational call to make an analysis on an application, it is necessary to make a technical analysis on all relevant application on inter-application dependencies (technical and functional). If a legacy application which needs to be phased out has dependencies on other applications and vice-versa, an impact analysis needs to be made. Following are few considerations need to be made.
·Applications transmitting data.
·Applications receiving data.
·Architecture standards of the applications and the interdependent and potentially impacted applications.
Activity 3: Information system functional (capability) modeling
(IAF's Logical IS/IT, TOGAF's Phase C: Information Systems Architectures)
ARISidentifies information system functions as IT capabilities. This name best captures this aspect. Depending on the complexity of the application, either a complete architecture development lifecycle (from business to IS/IT) or a direct functional mapping can be done. A mix of a top-down and vice versa approach is to be used to identify and map the IS Functions to the supporting IT Applications. Mark a cross or a percentage of coverage of the functionality.
I have developed a very smart analysis report using ARIS which populates functionality coverage. However a level based modeling approach is to be used. This works like charm and very simple to manage, though it looks a bit complicated. We were able to model and make analysis with ease and intuitively. A simple example is shown below. Function 1 is broken down into further details and its lower level functionality is also mapped to the applications which support it. For example, resource management which is functionality can be provided by multiple applications. But there can be very important differences in its lower level details which may or may not be supported by other applications.
App 1
App 2
App 3
App 4
Function 1
40%
60%
80%
20%
Function 2
35%
40%
100%
0%
Function 3
0%
%
100%
0%
…
….
App 1
App 2
App 3
App 4
Function 1.1
100%
100%
100%
100%
Function 1.2
100%
100%
100%
Function 1.3
Function 1.4
100%
Function 1.5
100%
100%
Activity 4: Analysis
(TOGAF’ Phase E: Opportunities and Solutions)
After identifying gaps and convergences, prepare a road map to phase-out and build if needed.
It is well understood that all business activities do not exist in vacuum but they exist and are shaped and as well as shape the context environment they operate in, are context based, as they exist in a unique environment. Understanding the fundamental factors which are part of the context or environment is vital (Business in context By David Needle). In The Art of War", role played by fundamental factors are described as "he who knows them will be victorious; he who knows them not will fail." One needs to consider these factors and understand how they affect the Project.
Alignment with business and technology vision, strategy and principles: This forms the basis for guiding the Organization’s architecture, its modeling and its underlying principles, methodology, constraints, decisions, scope and usage. This is not only a characteristic but is in the very nature of Enterprise Architecture and its modeling. And the Enterprise modeling project should be dynamic reflecting the changes to the business strategy (TOGAF, Rosemann. M 2006, Stevens et al, 2003, King 1995, Schekkerman, 2003; Delen, 2005) and thus need to realign.
Involves high Collaboration: it is important that during development cycle of Models, it is necessary to involve the various experts, stakeholders and users. (Alur and Dill, 1994; Chirichiello and Sala, 2005; Clarke and Peled, 2000). Though all these parties are either interviewed or communicated with in other ways, there is often a lack in the skills or in the time to actively participate in the modeling effort (Renger et all, 2008). This is particularly true for large distributed organizations. This also raises “Communication Issues”. Though analysts and architects might have mental models, visions for solution designs and meta-models, they often lack the adequate means of articulating and communicating them and their purpose in terms familiar to all stakeholders involved (Renger et all 2008; Clarke et al 1995). Enterprise Modeling thus requires high level of continuous correlation among all stakeholders (Delen et all, 2005).
Large organizations such as ST have become increasingly distributed, with information sources dispersed in multiple locations which makes effective collaboration for model management and knowledge access very difficult (Brown and Duguid, 1998; Ba et all 2008). To develop a comprehensive and coherent view of the enterprise, the various models must be correlated to facilitate understanding of the relationships and constraints between the elements represented in the various models which calls for decision-makers to collaborate to detect conflicts and inconsistencies between models, identify missing information, and calculate the impact of changes in one aspect of the enterprise on other aspects (Delen and Benjamin, 2005).
Balance of Scope: Enterprise level architecture involves a scope which spreads across multiple domains such as Business, IT, Data, Infrastructure and Organization resources. There are multiple purposes for Modeling such as Sarbanes-Oxley Act, ISO 9000 audit, knowledge base, business process engineering and Technology architecture work. Adopted from TOGAF’s dimension of scope of an Enterprise Architecture, the following has been identified as the dimension of scope for Enterprise Modeling.
·The breadth of coverage (Horizontal coverage) of the enterprise.
·The level of details (Vertical coverage).
·Domains to be covered (business, data, application, technology).
·Time horizon.
·The architectural assets (Models to be created, reused, recreated or modified, and their conditions for use.
A guiding principle for the scope for Enterprise Architecture modeling is “Good, is Good enough” (Delen and Benjamin, 2005). An enterprise model is not independent from one another an each model describes an aspect that it depends on, and is constrained by aspects described in other models. Delen and Benjamin, (2005) suggest a critical characteristic of enterprise models is that all model types are equally important in describing an enterprise. The goal of a model is to address comprehensively the types of questions being posed by decision-makers, not to provide the most detailed analysis possible. Shapiro, Charles (2004).
Method and discipline: Enterprise architecture is principled based. It lays down methodology which should be followed. As the various enterprises model types focus on different domains of an organization, such as data, activity, process, information system and organizational structure and to understand the entire enterprise it is the relationships and integration between the various model types from the different domains. This requires a method to support to support such integration. (Delen et all, 2005; Vernadat
, 2002). Delen et all (2005) provide reasons of correlation and maintenance problems with the various type of model from different domain captured, represented, and stored when using a standalone application. Modeling methods and tools are seen as complex, non integrated, time-consuming, expensive, and usable only by experts with a specific set of skills who are difficult to find (Delen et all, 2001; Mize et all, 1992; Vernadat, 2002; Williams 1994).
Requires High Buy-in and should handle Corporate Politics : TOGAF describes this factor this as "There is a similarity between enterprise architecture and architecture in the physical world, in that politics has an important role to play in the acceptance of both architectures. In the real world, it is the dual politics of the environment and commerce, while in the world of enterprise architecture a consideration of corporate politics is critical. An enterprise architecture imposed without appropriate political backing is bound to fail". The organization culture and resistance to change creates an environment which inhibits the Enterprise modeling initiative.
Reference:Alur, R., Dill, D.L.: A theory of timed automata. Theoretical Computer Science 126(2), 183 - 235 (1994)
Brown JS, Duguid P (1998) Organizing knowledge. California Manage Rev 40(3):90–111
Delen, Dursun;Benjamin Perakath C. ; Towards a truly integrated enterprise modeling and analysis environment.Computers in Industry Aug2003, Vol. 51 Issue 3, p257
King, W.R. (1995, Winter). "Creating a Strategic Capabilities Architecture," Information Systems Management, 12(1), pp. 67-69
http://www.opengroup.org/architecture/0404brus/speakers/schekkerman_jaap.htm
Michiel Renger , Gwendolyn L Kolfschoten ., and Gert-Jan de Vreede: Challenges in Collaborative Modeling:A Literature Review: Advances in Enterprise Engineering I 4th InternationalWorkshop CIAO! and 4th InternationalWorkshop EOMAS, held at CAiSE 2008 Montpellier, France, June 16-17, 2008
Rosemann, Michael Potential pitfalls of process modeling: part A Business Process Management Journal, Vol. 12, No. 2. (March 2006), pp. 249-254.
Rosemann, Michael Potential pitfalls of process modeling: part B Business Process Management Journal, Vol. 12, No. 3. (March 2006), pp. 377-384.
Vernadat F.B. (1997). Enterprise Modelling Languages ICEIMT'97 Enterprise Integration - International Consensus. EI-IC ESPRIT Project 21.859.
My thesis researches the use of the Balance scorecard (BSC) approach to evaluate the performance of ”Enterprise Modeling” intiatives within organizations. The Delone & Mclean IS success measurement theory was used within the Enterprise Modelng context, to systematically identify the dependent sucess measurement variables and their inter relationships which were applied to the balance scorecard. A case-study is made with ST Microelectronic's enterprise modeling initiative. The following are the deliverables for my thesis • Enterprise Modeling environmental context factors • Enterprise Modeling success measurement dependent variables • Enterprise Modeling key success factors • Enterprise Modeling performance measurement system development using Balance scorecard. • Enterprise Modeling strategy map. • Enterprise Modeling measures and metrics.
I have uploaded a draft version of the BCS for EA modeling, which is also published in my thesis.
I got my TOGAF 8 certification finally. I got a 50 % reduction on the exam because I bought the book. I was actually rewarded for not torrenting the same (I did not find it). However I can breathe now. Here are some points I want to put forward to anyone who wants to write the exam.
Buy the exam preparation book online :)
They ask silly questions on details. Best way to prepare for them is to take all the sample tests.
Prepare everyday. I had broken up with my ex, so I had the time :p
Common sense
Take the exam to make you learn. Yeah the certification is cool on your resume, but still.
After you spend some time, you start seeing a better picture into the world of EA
EA folks love documentation. So there is loads of it in TOGAF, and you may get lost in it. Try to find the simplicity in it.
Kaplan and Norton have identified the following the 5 principles of that guide the development of the strategy map. The principles have been modified to fit the Enterprise Architecture context.
Strategy balances contradictory forces: EA’s short term resource expense should balance the benefits realized mainly on a long term return time horizon
Strategy is based on a differentiated customer value proposition. Satisfying customers needs the vital source of sustainable value creation. The targeted customer segments of the EA initiative need to be identified and a value proposition need to be formulated.
Value is created through internal processes. Effective and aligned internal processes of the enterprise modeling initiative, determine how value gets created and sustained for customers. Focus is on critical few internal processes that deliver the differentiating value proposition
Strategy consists of simultaneous, complementary themes. The formulated key internal process, occur parallel and in many situations complement each other. However, they do not always deliver benefits at the same time. Hence care is to be taken so that, they are formulated, evolve and measured at appropriate intervals to create a sustaining growth.
Strategic alignment determines the value of intangible assets. The future learning and growth perspective, describes the EA initiative’s intangible assets and their role in the strategy.
I find work done by an EA guru, Jaap Schekkerman in Extended Enterprise Architecture Maturity Model Support Guide SM Version 2.0, an exceptional starting point to use maturity based KPIs to measure the objectives indicated in the strategy map.
.jpg)