Search Results for “open group” – Page 59

The Decision Model, Enterprise Architecture, ArchiMate and “The Decision Modeler”

May 27, 2013 by BizzDesign Staff

In my previous post I discussed my Three Decision Model Predictions and how they were realised by BiZZdesign ‘<a href=”http://www.bizzdesign.com/tools/the-decision-modeler/” target=”_blank”>The Decision Modeler’</a> – a new TDM tool.In this post I shall first explore the relationships between The Decision Model (TDM) and various Enterprise Architecture and design models, and why it is important to be able to model the dependences between TDM and other design and IT domains. Then I will show that BiZZdesign, using “The Decision Modeler” and ArchiMate tools, has become the first vendor to enable TDM models to form inter-model relationships and the advantages that brings to IT and the business.Wikipedia defines <a href=”http://en.wikipedia.org/wiki/Archimate” target=”_blank”>ArchiMate</a> (a technical standard of the Open Group) “[as] an open and independent enterprise architecture modelling language to support the description, analysis and visualization of architecture within and across business domainsin an unambiguous way.”<h2 class=”p1″>The Big Ball of Mud</h2>It was Foote & Yoder who in 1997 described early application software as being a “big ball of mud” because all the aspects and concerns of an application were all mixed together without any perceivable architecture. Later, it became apparent (see figure 1) that if one could separate out each aspect or concern of an application into its own component model, that it would be much easier to develop and maintain separately each aspect as well as the entire application.<img alt=”Balls of mudd or software applications?” src=”http://www.bizzdesign.com/assets/BlogDocuments-2/20130528_SuleimanShehu/The-Decision-Modeler-software-applications_400x307.png” style=”width: 400px; height: 307px;” title=”Software applications are balls of mudd”/>However there was one aspect which did not have a rigorous technology independent model and that was the business logic component, or business rules. This problem was solved with the invention of <a href=”http://www.kpiusa.com/index.php/The-Decision-Model/the-decision-model.html” target=”_blank”>The Decision Model</a> (TDM). All previous attempts had failed in creating a modelling language that could both tame the complexity of business logic and at the same time make it understandable to both business and IT users.One of the brilliant insights that the inventors of The Decision Model (Barbara Van Halle and Larry Goldberg) had was to tame the complexity of business logic using “business decisions” as a first class business logic concept, and then to invent a business logic model based on the inherent structure of logic and the business logic required to reach a business decision.The next insight they had was to choose a graphical notation that was simple for the business to understand yet expressive enough for IT; and then to marry this graphical notation with the 15 The Decision Model principles (declarative, structural and integrity principles) required to provide The Decision Model models with logical rigour.For further information on the 15 The Decision Model principles read the book “<a href=”http://www.amazon.com/Decision-Model-Framework-Technology-Management/dp/1420082817″ target=”_blank”>The Decision Model : A Business Logic Framework Linking Business and Technology” by Barbara von Halle and Larry Goldberg.</a>Business and IT could now use The Decision Model to extract all the business logic that are embedded within existing enterprise architecture, design and IT models and code into separate The Decision Model models, each linked to a business decision that the business wants to manage.<h2 class=”p1″>Integrating The Decision Model models with other models</h2>Having separated out from the “big ball of mud” and created The Decision Model models there is also a need for the integration and connections between The Decision Model models and other design and IT models to be modelled for the following reasons:<ul><li class=”li2″>Creating Decision-aware process models. Having extracted business logic from a process model and created one or more The Decision Model model, it is essential that a connection between a process task that is to execute a business decision and the The Decision Model model for that business decision. This connection can be modelled graphically using shared metadata (in this case the name of each the business decision that is to be evaluated (see figure 2). in BPMN notation the connection point is the name of the business rule task having the same decision name as a The Decision Model model. Figure 2 (taken from The Decision Modeler) shows the link between a business rule tasks (in the process domain) and the The Decision Model models (in the business logic domain). <img alt=”Business rule tasks and The Decision Model” src=”http://www.bizzdesign.com/assets/BlogDocuments-2/20130528_SuleimanShehu/The-Decision-Modeler-rule-tasks_399x283.png” style=”width: 399px; height: 283px;” title=”link between a business rule tasks and the The Decision Model models”/> In fact since business rule tasks are determining a business decisions and should really be called decision tasks. It is possible in BPMN to a define decision task as a stereotype of a business rule task and then to decorate the decision task with the The Decision Model blue octagon, to differentiate between an ordinary business rule task and a decision task. The Decision Model models do not implement actions directly; they only determine decisions based upon the execution of business logic. The results from the execution of a The Decision Model model can be returned to a decision gateway in the process model; which then determines and routes the subsequent actions that are to be executed based on the results returned. If an executable BPM modelling language like BPMN 2.0 is used, then it is possible to execute the BPMN process models in a BPM engine which consumes The Decision Modeler models in the form of Decision Services running in a business rules engine. </li> <li class=”li2″> Enable the Model-Driven Application (MDA) generation of code and other executable artefacts. Figure 3 shows the natural connections that exist between The Decision Model models and many types of models, these include UML, Logical data models, Use Case, Object Model, Fact Models, Business Process Models, etc.Once all the dependencies between a The Decision Model model and other dependant models are determined and modelled it is often possible for software to convert these models into executable artefacts with reduced programmer input leading to increased productivity and reduced defects. <img alt=”The Decision Model has natural connections with other models” src=”http://www.bizzdesign.com/assets/BlogDocuments-2/20130528_SuleimanShehu/The-Decision-Modeler-natural-connections_400x311.png” style=”width: 400px; height: 311px;” title=”Natural connections between The Decision Model and many other models”/> MDA-driven and The Decision Model-based applications offer the potential for a new frontier in enterprise applications. Gone will be the days of expensive consultants tailoring complex enterprise applications where all the business logic has been hard-coded into the application code. Instead a customer need only tailor the relevant The Decision Model models (provided by the enterprise application vendor) to their requirements and then “re-generate” the enterprise application – saving substantial costs and increased business agility. This The Decision Model frontier is yet to arrive but I predict it will be 5 years before such applications arrive – driven by the next generation of agile The Decision Model-driven enterprise application vendors. </li> <li class=”li2″> Using The Decision Model to Manage IT Operational Systems. Many middleware and Service Oriented Architecture (SOA) vendors are now designing their technologies so that a combination of business rules, complex event and BPM engines can be used to model and implement the business logic required to operate and manage their infrastructure. <img alt=”Service Oriented Architecture” src=”http://www.bizzdesign.com/assets/BlogDocuments-2/20130528_SuleimanShehu/The-Decision-Modeler-service-oriented-architecture_316x272.png” style=”width: 316px; height: 272px;” title=”Service Oriented Architecture (SOA)”/> In fact many Enterprise Service Bus (ESB) middleware contain the ability to perform routing based on dynamic rule bases. There is nothing to prevent the business logic that an ESB requires to be developed and maintained using from The Decision Model models. The ability to connect The Decision Model models that are being used to manage IT middleware (such as Figure 4) to components within the architecture is an exciting new development for The Decision Model. Until now, The Decision Model was being considered primarily for developing business applications rather than for controlling and managing complex IT execution platforms and middleware. It is important to realise that The Decision Model models can be automatically converted not only into rules that can executed in rules engines but can be converted into languages such as Java, XML, etc. The ability to model the inter-model relationships between models of IT infrastructure components and The Decision Model models will be required to meet traceability and governance requirements. </li> <li class=”li2″> Linking The Decision Model with Strategic Models. One of the advantages of ArchiMate is that it includes the Motivation extension for modelling (among others) stakeholders, business goals, principles and requirements, which can be linked to the elements in the architecture that realize them. In this way, we can achieve full traceability from goals and requirements to architecture, design and implementation. <img alt=”Motivation Extention” src=”http://www.bizzdesign.com/assets/BlogDocuments-2/20130528_SuleimanShehu/The-Decision-Modeler-motivation-extention-metamodel_550x238.png” style=”width: 550px; height: 238px;” title=”Motivation Extention Metamodel”/> Figure 5 shows the key concepts of the Motivation metamodel. The Drivers are the things, internal or external that creates, motivates change in the organisation. Assessment is defined as the outcome of some analysis of some driver. Goals are the intended end states that a stakeholder seeks to achieve. Requirement is defined as a statement of needs that must be realised by a system. In fact Requirements model the properties of the elements (e.g. business process, business decision logic, application component) that are needed to achieve the “ends” that are modelled as goals. Requirements can therefore be considered the “means” to realise goals. The The Decision Model models that are of strategic interest to stakeholders are those key business decisions that are critical or important to the realisation of the strategic goals. Since The Decision Model is about modelling the business logic behind business decisions these strategic The Decision Model models can be considered high-level requirements that should be linked to Requirements in the Motivation model. Not all The Decision Model models should, in my view, be directly linked to Requirements. For example data-quality The Decision Model models, valuable as they are need not be linked to Requirements. Of course some The Decision Model models need not be directly linked to the Motivation model. For example a Requirement in the Motivation model may be linked to a ArchiMate process model in the business layer which may then be linked to a TDM and BPMN models (see figure 10). However linking The Decision Model models that realise strategic business decisions, that are required to realise business goals, are of immense value to stakeholders. Because these The Decision Model models can be linked to metrics which then drive a corporate balanced scorecard forming a feed-back loop that is required for good strategic planning and implementation. More information on this will be discussed in my third guest post ”Business Performance Management and The Decision Model”. </li> <li class=”li2″> Strategy Models and Skeleton The Decision Model models When modelling and connecting The Decision Model models with strategic and other Enterprise Architecture models it is important to realise that The Decision Model models can be linked to Enterprise Architecture and other design models in their skeleton form before individual rules within Rule Families have been modelled. Assuming that one is using the top-down methodology for developing The Decision Model models one could start with the business decision and then add the supporting Decision Rule Family. This initial minimal The Decision Model model can be linked to other models including strategic motivation models. Then later in the The Decision Model design process these initial The Decision Model skeleton models can expanded until the model is complete. Then the process of completing the individual rows (business rules) in each Rule Family table. The diagram below shows a The Decision Model model in a skeleton form. <img alt=”Skeleton form” src=”http://www.bizzdesign.com/assets/BlogDocuments-2/20130528_SuleimanShehu/The-Decision-Modeler-skeleton-form_450x320.jpg” style=”width: 450px; height: 320px;” title=”The Decision Model model in a skeleton form”/> </li> <li class=”li2″> A Skeleton TDM model The diagram below show what you see when you drill down and expand a Rule Family and see the contents of a Rule Family Table (shown in yellow below). Each row within a Rule Family Table is equivalent to a single rule. Enterprise Architecture The Decision Model modelling does not require that you use completed The Decision Model models. Over time during the design phase the The Decision Model models will be completed and the inter-model links will ensure that the latest The Decision Model model will always be linked. <img alt=”Rule families” src=”http://www.bizzdesign.com/assets/BlogDocuments-2/20130528_SuleimanShehu/The-Decision-Modeler-rule-families_450x327.png” style=”width: 450px; height: 327px;” title=”The Decision Model rule families”/> </li></ul> <h2 class=”li2″>BiZZdesign, ArchiMate and The Decision Modeler</h2>BiZZdesign is the only tool vendor that has produced TDM-aware tools that enable the rich modelling landscape outlined above can be realised.<h2>The Decision Modeler – Integrates Business Logic, Information and Processes</h2>The integration between business logic, Information and Processes is illustrated in figure 7 and is directly implemented within The Decision Modeler; with business logic being modelled by The Decision Model, the information domain modelled by UML and the process domain modelled by Amber and BPMN 2.<img alt=”Information and processes can be related” class=”left” src=”http://www.bizzdesign.com/assets/BlogDocuments-2/20130528_SuleimanShehu/The-Decision-Modeler-integration-of-business-logic-information-processes_301x275.png” style=”width: 301px; height: 275px; float: left;” title=”Integration of business logic and information and processes”/><img alt=”Policy and claim relation” class=”right” src=”http://www.bizzdesign.com/assets/BlogDocuments-2/20130528_SuleimanShehu/The-Decision-Modeler-relation-policy-claim_300x192.png” style=”width: 300px; height: 192px; float: right;” title=”Relationship between policy and claim”/> Figure 8 show the relationship between Policy and Claim classes and their attributes in the information domain using UML. Figure 9 shows that same information model with a summary of how The Decision Modeler integrates Process, The Decision Model, Rule Family, Rule Family Tables, Fact Types, Glossary and UML.<img alt=”Modeling domains summary” src=”http://www.bizzdesign.com/assets/BlogDocuments-2/20130528_SuleimanShehu/The-Decision-Modeler-summary-relations-modeling-domains_450x365.png” style=”width: 450px; height: 365px;” title=”Summary of relations between modeling domains”/><h2 class=”p1″>Integrating ArchiMate with TDM – The BiZZdesign Advantage</h2>There is no doubt that The Decision Modeler integration of The Decision Model, UML and BPMN 2 (and Amber) has resulted in an excellent TDM tool. However, BiZZdesign integration of the ArchiMate enterprise architecture modelling standard (within its Architect toolset) with The Decision Model sets BiZZdesign as the clear leader in The Decision Model tool innovation.<img alt=”Interrelationships” src=”http://www.bizzdesign.com/assets/BlogDocuments-2/20130528_SuleimanShehu/The-Decision-Modeler-interrelationships_451x273.png” style=”width: 451px; height: 273px;” title=”Interrelationships”/>ArchiMate is particularly suited for modelling the interrelationships between different domains (see figure 10). So in an ArchiMate model we can show what the main products are; which business processes realize them, which information and business decisions are used in these processes, which applications support them, etc. Then we model the details in each of these domains in the appropriate languages, e.g., business processes in BPMN, business decisions and business logic in The Decision Model, information and applications in UML. If we use the same tool suite for these models, we can link these models to elements in the ArchiMate model (using references or inter-model relationships), to link to each other.ArchiMate is an extendable modelling language, for example:<ul><li class=”li2″>It is possible to define new attributes and relationships and to create new concepts based on the specialisation of existing concepts. </li> <li class=”li2″>It is possible to define new domain specific languages (DSLs) as user defined profiles. </li></ul><h2 class=”li2″>Conclusions</h2>All the inter-model relationships I have outlined in this post can be modelled by a combination of ArchiMate and The Decision Modeler. BiZZdesign decision to bring The Decision Model-awareness to ArchiMate’s extensive modelling capabilities is going to transform Enterprise Architecture and decision modelling practice.In one leap BiZZdesign has gone from a standing start, in The Decision Model tools, to being the most innovative The Decision Model tool vendor. In due course, other The Decision Model tool vendors will respond, but for now BiZZdesign leads the The Decision Model vendors with its modelling capabilities. <div class=”p1″ style=”background:#eee;border:1px solid #ccc;padding:5px 10px;”>Suleiman Shehu is the CEO, of Dublin based <a href=”http://www.azinta.com” target=”_blank”>Azinta Systems Ltd</a>. Azinta Systems is a business transformation, business integration and consultancy company. Azinta is a KPI The Decision Model consulting partner for the Europe, Middle-East and Africa (EMEA). Azinta has recently signed a strategic business partnership with BiZZdesign for EMEA region and Azinta will be providing TDM consulting and TDM methodology training services for those looking to start using TDM with the Decision Modeler. Suleiman can be contacted at Suleiman.shehu@azinta.com. </div>

What is Business Architecture? Part 2

May 21, 2013 by Open Group

By Allen Brown, President and CEO, The Open Group I recently wrote that I had heard and read the opinions of a number of people about what is Business Architecture, as I am sure many of us have but I wanted to understand it from the perspective of people who actually had Business Architect in … … Continue reading →

Redefining traceability in Enterprise Architecture and implementing the concept with TOGAF 9.1 and/or ArchiMate 2.0

May 10, 2013May 8, 2013 by Serge Thorn

One of the responsibilities of an Enterprise Architect is to provide complete traceability from requirements analysis and design artefacts, through to implementation and deployment.

Along the years, I have found out that the term traceability is not always really considered in the same way by different Enterprise Architects.

Let’s start with a definition of traceability. Traceable is an adjective; capable of being traced. Trying to find a definition even from a dictionary is a challenge and the most relevant one I found on Wikipedia which may be used as a reference could be “The formal definition of traceability is the ability to chronologically interrelate uniquely identifiable entities in a way that is verifiable.”

In Enterprise Architecture, traceability may mean different things to different people.

Some people refer to

· Enterprise traceability which proves alignment to business goals

· End-to-end traceability to business requirements and processes

· A traceability matrix, the mapping of systems back to capabilities or of system functions back to operational activities

· Requirements traceability which assists in quality solutions that meets the business needs

· Traceability between requirements and TOGAF artifacts

· Traceability across artifacts

· Traceability of services to business processes and architecture

· Traceability from application to business function to data entity

· Traceability between a technical component and a business goal

· Traceability of security-related architecture decisions

· Traceability of IT costs

· Traceability to tests scripts

· Traceability between artifacts from business and IT strategy to solution development and delivery

· Traceability from the initial design phase through to deployment

· And probably more

The TOGAF 9.1 specification rarely refers to traceability and the only sections where the concept is used are in the various architecture domains where we should document a requirements traceability report or traceability from application to business function to data entity.

The most relevant section is probably where in the classes of architecture engagement it says:

“Using the traceability between IT and business inherent in enterprise architecture, it is possible to evaluate the IT portfolio against operational performance data and business needs (e.g., cost, functionality, availability, responsiveness) to determine areas where misalignment is occurring and change needs to take place.”

And how do we define and document Traceability from an end user or stakeholder perspective? The best approach would probably to use a tool which would render a view like in this diagram:

In this diagram, we show the relationships between the components from the four architecture domains. Changing one of the components would allow doing an impact analysis.

Components may have different meanings as illustrated in the next diagram:

Using the TOGAF 9.1 framework, we would use concepts of the Metamodel. The core metamodel entities show the purpose of each entity and the key relationships that support architectural traceability as stipulated in the section 34.2.1 Core Content Metamodel Concepts.

So now, how do we build that traceability? This is going to happen along the various ADM cycles that an enterprise will support. It is going to be quite a long process depending on the complexity, the size and the various locations where the business operates.

There may be five different ways to build that traceability:

· Manually using an office product

· With an enterprise architecture tool not linked to the TOGAF 9.1 framework

· With an enterprise architecture tool using the TOGAF 9.1 artifacts

· With an enterprise architecture tool using ArchiMate 2.0

· Replicating the content of an Enterprise Repository such as a CMDB in an Architecture repository

1. Manually using an office product

You will probably document your architecture with the use of word processing, spread sheets and diagramming tools and store these documents in a file structure on a file server, ideally using some form of content management system.

Individually these tools are great but collectively they fall short in forming a cohesive picture of the requirements and constraints of a system or an enterprise. The links between these deliverables soon becomes non manageable and in the long term impact analysis of any change will become quite impossible. Information will be hard to find and to trace from requirements all the way back to the business goal that drives it. This is particularly difficult to achieve when requirements are stored in spread sheets and use cases and business goals are contained in separate documents. Other issues such as maintenance and consistency would have to be considered.

2. With an enterprise architecture tool not linked to the TOGAF 9.1 framework

Many enterprise architecture tools or suites provide different techniques to support traceability but do not really describe how things work and focus mainly on describing requirements traceability. In the following example, we use a traceability matrix between user requirements and functional specifications, use cases, components, software artifacts, test cases, business processes, design specifications and more.

Mapping the requirements to use cases and other information can be very labor-intensive.

Some tools also allow for the creation of relationships between the various layers using grids or allowing the user to create the relationships by dragging lines between elements.

Below is an example of what traceability would look like in an enterprise architecture tool after some time. That enterprise architecture ensures appropriate traceability from business architecture to the other allied architectures.

3. With an enterprise architecture tool using the TOGAF 9.1 artifacts

The TOGAF 9.1 core metamodel provides a minimum set of architectural content to support traceability across artifacts. Usually we use catalogs, matrices and diagrams to build traceability independently of dragging lines between elements (except possibly for the diagrams). Using catalogs and matrices are activities which may be assigned to various stakeholders in the organisation and theoretically can sometimes hide the complexity associated with an enterprise architecture tool.

Using artifacts creates traceability. As an example coming from the specification; “A Business Footprint diagram provides a clear traceability between a technical component and the business goal that it satisfies, while also demonstrating ownership of the services identified”. There are other artifacts which also describe other traceability: Data Migration Diagram and Networked Computing/Hardware Diagram.

4. With an enterprise architecture tool using ArchiMate 2.0

Another possibility could be the use of the ArchiMate standard from The Open Group. Some of the that traceability could also be achievable in some way using BPMN and UML for specific domains such as process details in Business Architecture or building the bridge between Enterprise Architecture and Software architecture.

With ArchiMate 2.0 we can define the end to end traceability and produce several viewpoints such as the Layered Viewpoint which shows several layers and aspects of an enterprise architecture in a single diagram. Elements are modelled in five different layers when displaying the enterprise architecture; these are then linked with each other using relationships. We differentiate between the following layers and extensions:

· Business layer

· Application layer

· Technology layer

· Motivation extension

· Implementation and migration extension

The example from the specification below documents the various architecture layers.

As you will notice, this ArchiMate 2.0 viewpoint looks quite similar to the TOGAF 9.1 Business Footprint Diagram which provides a clear traceability between a technical component and the business goal that it satisfies, while also demonstrating ownership of the services identified.

Another example could be the description of the traceability among business goals, technical capabilities, business benefits and metrics. The key point about the motivation extension is to work with the requirement object.

Using the motivation viewpoint from the specification as a reference (motivation extension), you could define business benefits / expectations within the business goal object, and then define sub-goals as KPIs to measure the benefits of the plan and list all of the identified requirements of the project / program. Finally, you could link these requirements with either application or infrastructure service object representing software or technical capabilities. (Partial example below).

One of the common questions I have recently received from various enterprise architects is “Now that I know TOGAF and ArchiMate… how should I model my enterprise? Should I use the TOGAF 9.1 artifacts to create that traceability? Should I use ArchiMate 2.0? Should I use both? Should I forget the artifacts…”. These are good questions and I’m afraid that there is not a single answer.

What I know is that if I select an enterprise architecture tool supporting both TOGAF 9.1 and ArchiMate 2.0, I would like to be able to be able to have a full synchronization. If I model a few ArchiMate models I would like my TOGAF 9.1 artifacts to be created at the same time (catalogs and matrices) and if I create artifacts from the taxonomy, I would like my ArchiMate models also to be created.

Unfortunately I do not know the current level of tools maturity and whether tools vendors provide that synchronization. This would obviously require some investigation and should be one of the key criteria if you were currently looking for a product supporting both standards.

5. Replicating the content of an Enterprise Repository such as a CMDB in an Architecture repository

This other possibility requires that you have an up to date Configuration Management Database and that you developed an interface with your Architecture Repository, your enterprise architecture tool. If you are able to replicate the relationships between the infrastructure components and applications (CIs) into your enterprise architecture tool that would partially create your traceability.

If I summarise the various choices to build that enterprise architecture traceability, I potentially have three main possibilities:

Achieving traceability within an Enterprise Architecture is key because the architecture needs to be understood by all participants and not just by technical people. It helps to incorporate the enterprise architecture efforts into the rest of the organization and it takes it to the board room (or at least the CIO’s office) where it belongs.

· Describe your traceability from your Enterprise Architecture to the system development and project documentation.

· Review that traceability periodically, making sure that it is up to date, and produce analytics out of it.

If a development team is looking for a tool that can help them document, and provide end to end traceability throughout the life cycle EA is the way to go Make sure you use the right standard and platform. Finally, communicate and present to your stakeholders the results of your effort.

Redefining traceability in Enterprise Architecture and implementing the concept with TOGAF 9.1 and/or ArchiMate 2.0

May 10, 2013May 8, 2013 by Serge Thorn

One of the responsibilities of an Enterprise Architect is to provide complete traceability from requirements analysis and design artefacts, through to implementation and deployment.

Along the years, I have found out that the term traceability is not always really considered in the same way by different Enterprise Architects.

In Enterprise Architecture, traceability may mean different things to different people.

Some people refer to

· Enterprise traceability which proves alignment to business goals

· End-to-end traceability to business requirements and processes

· A traceability matrix, the mapping of systems back to capabilities or of system functions back to operational activities

· Requirements traceability which assists in quality solutions that meets the business needs

· Traceability between requirements and TOGAF artifacts

· Traceability across artifacts

· Traceability of services to business processes and architecture

· Traceability from application to business function to data entity

· Traceability between a technical component and a business goal

· Traceability of security-related architecture decisions

· Traceability of IT costs

· Traceability to tests scripts

· Traceability between artifacts from business and IT strategy to solution development and delivery

· Traceability from the initial design phase through to deployment

· And probably more

The most relevant section is probably where in the classes of architecture engagement it says:

And how do we define and document Traceability from an end user or stakeholder perspective? The best approach would probably to use a tool which would render a view like in this diagram:

In this diagram, we show the relationships between the components from the four architecture domains. Changing one of the components would allow doing an impact analysis.

Components may have different meanings as illustrated in the next diagram:

There may be five different ways to build that traceability:

· Manually using an office product

· With an enterprise architecture tool not linked to the TOGAF 9.1 framework

· With an enterprise architecture tool using the TOGAF 9.1 artifacts

· With an enterprise architecture tool using ArchiMate 2.0

· Replicating the content of an Enterprise Repository such as a CMDB in an Architecture repository

1. Manually using an office product

2. With an enterprise architecture tool not linked to the TOGAF 9.1 framework

Mapping the requirements to use cases and other information can be very labor-intensive.

Some tools also allow for the creation of relationships between the various layers using grids or allowing the user to create the relationships by dragging lines between elements.

3. With an enterprise architecture tool using the TOGAF 9.1 artifacts

4. With an enterprise architecture tool using ArchiMate 2.0

· Business layer

· Application layer

· Technology layer

· Motivation extension

· Implementation and migration extension

The example from the specification below documents the various architecture layers.

5. Replicating the content of an Enterprise Repository such as a CMDB in an Architecture repository

If I summarise the various choices to build that enterprise architecture traceability, I potentially have three main possibilities:

· Describe your traceability from your Enterprise Architecture to the system development and project documentation.

· Review that traceability periodically, making sure that it is up to date, and produce analytics out of it.

What is Business Architecture?

April 30, 2013 by Open Group

By Allen Brown, President and CEO, The Open Group I have heard and read the opinions of a number of people about what is Business Architecture, as I am sure many of us have but I wanted to understand it from the perspective of people who actually had Business Architect in their job title. So … … Continue reading →

Developing standards to secure our global supply chain

April 9, 2013 by Open Group

By Sally Long, Director of The Open Group Trusted Technology Forum (OTTF)™ In a world where tainted and counterfeit products pose significant risks to organizations, we see an increasing need for a standard that protects both organizations and consumers. Altered or non-genuine products introduce the possibility of untracked malicious behavior or poor performance. These risks can damage … … Continue reading →

Exciting FACE™ Air Force Event – April 2

March 28, 2013 by Open Group

Coming on the heels of the release of Edition 2.0 of the FACE Technical Standard and recent procurement pull from the Army and Navy, The Open Group FACE™ Consortium is pleased to announce a groundbreaking FACE Air Force Technical Interchange Meeting and Exposition on April 2, 2013 at the Holiday Inn Dayton/Fairborn in Fairborn, OH, near Wright-Patterson Air Force Base. … Continue reading →

Case Experiences and Best practices Using ArchiMate® and TOGAF®

March 25, 2013 by BizzDesign Staff

Implementing Enterprise Architecture in any organization requires an effective method and a consistent way of modeling to build architecture models. The Open Group standards <a title=”proven, comprehensive and generic methodology and framework” href=”http://www.bizzdesign.com/consultancy/enterprise-architecture-management/togaf/#The Open Group Architecture Framework”>TOGAF</a>® and <a title=”open modeling language for architects to model and communicate Enterprise Architecture” href=”http://www.bizzdesign.com/consultancy/enterprise-architecture-management/archimate/#Architects need a unified framework to describe enterprise architectures”>ArchiMate</a>® are used worldwide to implement Enterprise Architecture. TOGAF® focuses on the method of implementing and maintaining Enterprise Architecture. ArchiMate® is an Enterprise Architecture modeling language standard. A lot of organizations in various markets worldwide use (a a combination of) these standards.On 28-March-2013 I will present a webinar via <a title=”Leading the development of open, vendor-neutral IT standards and certifications” href=”http://www.opengroup.org”>The Open Group</a> in which I will give an overview of some real-life case experiences in using ArchiMate® and TOGAF® for implementing Enterprise Architecture. The approach, deliverables and examples of the several case studies will be shared. Furthermore, practical do’s and don’ts in adopting ArchiMate® and TOGAF® will be discussed. Attendees of this webinar will benefit from the lessons learned, and will learn which aspects are typically important to consider when implementing Enterprise Architecture in any organization.<a title=”Register for this webinar” href=”https://opengroupevents.webex.com/ec0606l/eventcenter/enroll/join.do?confViewID=1003593497&theAction=detail&confId=1003593497&path=program_detail&siteurl=opengroupevents”>Registration details</a> for this webinar can be found on the Open Group website. <div class=”captionImage left” style=”width: 600px;”><img class=”left” src=”http://www.bizzdesign.com/assets/BlogDocuments-2/_resampled/resizedimage600255-Togaf-archimate-repository-reference-models.png” alt=”Togaf archimate repository reference models” title=”During the webinar Rob Kroese will explain TOGAF and archiMate” width=”600″ height=”255″/>ArchiMate® and TOGAF®</div>

Link Collection — March 24, 2013

March 24, 2013 by Brenda Michelson

LEAD Frameworks | LEAD Frameworks, Methods & Approaches

Speaking of Enterprise Architecture frameworks, this just crossed my radar via Twitter. Just passing it along, not an endorsement as I haven’t had a chance to dig in.

“LEAD is an abbreviation for “Layered Enterprise Architecture Development” and is often used as a synonym to describe the entire LEAD concept. The LEAD Frameworks refers to either the entire LEAD concept, or to a specific LEAD Framework. A certified LEAD practitioner is called a LEAD eXpert or a LEAD Architect.

The LEAD version 3.0 currently consists of 10 frameworks, 6 methods and 4 approaches that are all integrated to each other with supporting maps, matrices and models that can be used for all aspects of enterprise modelling e.g. business model, competencies, value, services, processes, information, applications, data, platforms, infrastructure and cloud as well as for transformation and innovation modelling.”

tags: enterprise_architecture entarch
#ogChat Summary – Business Architecture | The Open Group Blog

I participated in this Business Architecture tweet jam. It was fun and interesting. No surprise, I have a different view than the rest. I’m @bmichelson in the linked post.
“The Open Group hosted a tweet jam (#ogChat) to discuss the evolution of Business Architecture and its role in enterprise transformation. In case you missed the conversation, here is a recap of the event.”

tags: business_architecture business_analysis #entarch #bizarch
Amazon launches “Send to Kindle” button for web publishers and WordPress blogs — paidContent

I added this to elementallinks.com. Look for the “Send to Kindle” icon at the end of my posts. I tested on 3 devices: Kindle Touch, iphone and ipad, works well.

“Amazon is now allowing publishers to add “Send to Kindle” buttons to their websites and WordPress blogs, the company announced on the Kindle blog Tuesday.”

tags: kindle blogs
Taotwit’s Too-Big-To-Tweet: TOGAF Good or Bad? – Definitely Ugly!

Nigel raises some great points on TOGAF and the challenges in applying EA frameworks in the real-world. Not to mention, a world where english is NOT the first language.

“TOGAF just tries too hard and ends up failing on a few counts: it’s too comprehensive to be a usable framework and not specific enough to be a methodology.”

However, Nigel also recognizes that TOGAF is currently the only credible option to get newbies up-to-speed.

So, how do we change that?

tags: entarch enterprise_architecture togaf
Big data in the age of the telegraph – McKinsey Quarterly – Organization – Strategic Organization

Decision-making and authority placed nearest the real-time data, circa 1854.

“Daniel McCallum created the first organization chart in response to the information problem hobbling one of the longest railroads in the world. In surprising contrast to today’s top-down organization pyramids, in McCallum’s chart the hierarchy was reversed: authority over day-to-day scheduling and operations went to the divisional superintendents down the line, who oversaw the five branch lines of the railroad. The reasoning: they possessed the best operating data, were closer to the action, and thus were best placed to manage the line’s persistent inefficiencies.”

Plus, cool 1854 org charts… flow with data.

tags: mckinsey data real-time active-information
The Arguments Your Company Needs – Michael Schrage – Harvard Business Review

What is your company’s most important (current / ongoing) argument? Is it focused on strategy, value or individuals?

“Asked several years ago to describe the most important argument taking place at Walmart, then-CEO Lee Scott immediately replied, “The size of our stores.” The world’s largest retailer was debating just how small its footprints and formats could be while still serving customer needs and its own brand equity promise. That conversation, Scott said, provoked a lot of new thinking and analysis.”

..”All firms have strategies and cultures. But sometimes the quickest and surest way to gain valuable insight into their fundamentals is by asking, “What’s the most important argument your organization is having right now?””

tags: schrange hbr business_analysis

Posted from Diigo. The rest of my favorite links are here.

A Comparison of the Top Four Enterprise-Architecture Methodologies

March 23, 2013March 23, 2013 by Amitabh Apte

I recently came across a very good article with above title written by Roger Sessions on the Microsoft Network. It is
one of the few articles which is backed up by good amount of industry research,
rich usage of references and very precise analysis of Enterprise Architecture
literature.

In this article Roger compares following four leading
Enterprise Architecture Frameworks;

The Zachman Framework for Enterprise
Architecture
The Open Group Architecture Framework
Federal Enterprise Architecture
Gartner Enterprise Architecture Framework

He does so within the context of a fictional company that is facing
some very nonfictional operations problems. These problems include:

IT
systems that have become unmanageably complex and increasingly costly to
maintain.
IT
systems that are hindering the organization’s ability to respond to
current, and future, market conditions in a timely and cost-effective
manner.
Mission-critical
information that is consistently out-of-date and/or just plain wrong.
A
culture of distrust between the business and technology sides of the
organization.

Roger concludes that, “these methodologies are quite different
from each other, both in goals and in approach. This is good news and bad. It
is bad news, in that it increases the difficulty for many organizations in
choosing one single enterprise-architectural methodology. How do you choose
between methodologies that have so little in common? Choosing between Zachman
and TOGAF, for example, is like choosing between spinach and hammers. But the
good news is that these methodologies can be seen as complementing each other.
For many organizations, the best choice is all of these methodologies, blended
together in a way that works well within that organization’s constraints.”

Though the whitepaper is probably
getting a bit dated (Mar 2007) especially given the new releases from TOGAF 9.1
and Zachman have advanced the EA field in leaps and bounds, it is nonetheless a
very good piece of academic comparison grounded in some real life business
situation.

I have personally done similar compare
and contrast analysis between various EA frameworks on this blog through posts
such as, EA
Frameworks in Complete Harmony, Zachman
Complexity and Change, EA
– Different Perspectives. These can be referenced as further reading on
this topic.

Business Architecture

March 23, 2013 by Adrian Campbell

Tom Graves recently participated in an Open Group TweetJam on Business Architecture. You can read about the results of this at http://weblog.tetradian.com/2013/03/20/opengroup-on-bizarch/ Unfortunately I didn’t hear about this in time to participate but I thought I’d record my own thoughts here. The questions were: How do you define Business Architecture? What is the role of the business architect? What real world business problems […]

#ogChat Summary – Business Architecture

March 20, 2013 by Open Group

The Open Group hosted a tweet jam (#ogChat) to discuss the evolution of Business Architecture and its role in enterprise transformation. In case you missed the conversation, here is a recap of the event. … Continue reading →