#eavoices

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

by

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:

image

 

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:

 

image

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.

clip_image006

 

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.

clip_image008

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.

 

clip_image010

 

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.

 

image

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.

clip_image014

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).

 

clip_image016

 

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:

 

image

 

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.

The New IT Reality Demands a Participative Workforce

by

Last week my report “Field Research Summary: The Changing IT Career” was published on Gartner.com. This report summarizes the findings from our field research project focused on how goals, expectations and trends are affecting IT careers from the practitioner’s point of view. This field research incorporated both a Gartner Research Circle survey and in-depth interviews […]

The post The New IT Reality Demands a Participative Workforce appeared first on Mike Rollings.

Top Technology Trends and CIO Priorities for 2013

by
I have been regularly writing about emerging Information Technology trends on this blog. The CIO priorities for future are often linked to these trends but they also do influence the Information Technology trends in return. Gartner who is at the forefront of research in this space has recently released their research report outlining their top 10 strategic technology trends for 2013. The complete report can be accessed here but a brief summary of this research along with my own summary comments are as follows:
  1. Mobile Devices Battles – Windows 8 is here. Is your organisation going to deploy it? If yes, what will be the impact on your BYOD policy. Windows 8 tablets and smartphones will gain in prominence. What does this mean for your iOS and Android support model?
  2. Mobile Apps and HTML 5 –  Mobile app and web technologies are fast maturing and are influencing native application development too. How will you manage the hybrid web / native development frameworks?
  3. Personal Cloud – Online applications and services are transforming consumer technology. How will this effect your organisation? Windows 8 with Skydrive is an example of this trend.
  4. The Internet of Things – Becoming more mainstream now. What innovative business models will you create in next three years to benefit from IoT?
  5. Hybrid IT and Cloud Computing – As Cloud Computing evolves and matures new business and operating models are emerging. IT departments of large oranisations will be expected to act as service brokers in such hybrid models.
  6. Strategic Bid Data – Big Data has become a major driver of IT spending recently but going forward the trend will be to integrate this better with Data warehouses and Data Integration Infrastructure
  7. Actionable Analytics – Business needs real-time decision making and forward looking analytics. How can you embed this in real time applications?  
  8. Mainstream In-Memory Computing – How will In-Memory Computing disrupt the application architectures and how will your manage the operating and data governance requirements?  
  9. Integrated Platforms and Ecosystems – How do you balance vendor lock-in with benefits of integrated platforms?
  10. Enterprise APP Stores – The success of consumer App stores will drive organisation’s own enterprise App stores but this needs to balanced with security and support concerns.
Deloitte has been a recent welcome entrant in the Technology Trend publishing business with it releasing its fourth annual technology trend report recently. The folks at Deloitte have taken an interesting approach to this as they have grouped trends in two classifications or categories:  “Disruptors” are opportunities that can create sustainable positive disruption in IT capabilities, business operations, and sometimes even business models. “Enablers” are technologies in which many CIOs have already invested time and effort, but which warrant another look because of new developments or opportunities. Deloitte lists trends such as Influence of Mobility, Social, Analytics, Cloud as Disruptors while listing as Gamification, Refocussing on ERP and Security focus as Enablers. 

In one of my previous blog posts I had written about five forces shaping the CIO agenda. Very briefly, they were listed as, Business Services, Application Services, Cloud Computing, Consumerisation of Technology and Business Analytics. If above published 2013 trend research is taken into account then I would like to redefine them as follows:

  1. Evolution of Cloud Computing – Private, Public, Hybrid, Community, Personal
  2. Consumerisation of Technology – Windows 8, Tablet, Smart phone adaption
  3. Mainstream nature of Data Analytics – Big Data coming to Data Warehousing 
  4. Proliferation of Web APPs – Enterprise APP stores on the line of Mobile APP Stores
  5. Increasing Integration of Platforms – e.g. Rise of Appliances such as EXADATA
I think that the business and application services are slowly merging into the APP Store philosophy while the business analytics has gone mainstream since 2011. Cloud and increasing integration of platforms is a trend which has matured since past few years and is probably going to get through further rounds of evolution in coming years. It is interesting that no one is yet talking about explicit influence of Social as much as any of above trends. 

From information architecture to evidence-based practice

by

@bengoldacre has produced a report for the UK Department for Education, suggesting some lessons that education can learn from medicine, and calling for a coherent “information architecture” that supports evidence based practice. Dr Goldacre notes that in the highest performing education systems, such as Singapore, “it is almost impossible to rise up the career ladder of teaching, without also doing some work on research in education.”

Here are some of his key recommendations. Clearly these recommendations would be relevant to many other corporate environments, especially those where there is strong demand for innovation, performance and value-for-money.

  • a simple infrastructure that supports evidence-based practice
  • teachers should be empowered to participate in research
  • the results of research should be disseminated more efficiently
  • resources on research should be available to teachers, enabling them to be critical and thoughtful consumers of evidence
  • barriers between teachers and researchers should be removed
  • teachers should be driving the research agenda, by identifying questions that need to be answered.

Clearly it is not enough merely to create an information architecture or knowledge infrastructure. The challenge is to make sure they are aligned with an inquiring culture.

to be continued …

Ben Goldacre, Teachers! What would evidence based practice look like? (Bad Science, March 2013)

Why information architecture needs systems thinking

by

If a factory is torn down but the rationality which produced it is left standing, then that rationality will simply produce another factory. If a revolution destroys a government, but the systematic patterns of thought that produced that government are left intact, then those patterns will repeat themselves … There’s so much talk about the system. And so little understanding.

Source: Robert Pirsig, Zen and the Art of Motorcycle Maintenance, 1974

We who labor at the crossroads of structure and behavior have learned the hard way that content management is far messier than garbage collection and “the system always kicks back.”

Source: Peter Morville, Editorial: The System of Information Architecture (Journal of Information Architecture. Vol. 3, No. 2., 2012) 

Churchman’s interest in computing reaches extensively beyond the metaphor of inquiring systems. He addresses many issues with the state of MIS research of his time, including the tendency of IS researchers to focus on “safe” issues such as “structure of files, retrieval techniques, automatic abstracting, and the like” (Churchman 1968, p.111). He indicates that the majority of such research is not consistent with the systems approach as it focuses on transactions rather than the true goals or benefit of the system. Churchman is also quite visionary as he predicts the ubiquitous role of computers in everyday life. With the ability to “find facts” readily, Churchman predicted that information systems will actually work to reinforce a user’s Weltanschauung (world-view), as the user would screen information based on his Weltanschauung. In order to expand use MIS to expand the user’s view to one that is more holistic, Churchman envisioned a “deadly enemy” proposal for the design of an information system. The main role of this deadly enemy is for the system to propose information results based on assumptions that are opposite of the user’s information request, thereby revealing to the user his fundamental assumptions and at the same time questioning them (Churchman 1968, p. 122-123).

Source: Nicholas Berente, C West Churchman: Champion of the Systems Approach quoting Churchman, C.W. (1968) The Systems Approach, Dell Publishing Co.

See also Kristo Ivanov, The systems approach to design, and inquiring information systems (2001)

We Ought to Know the Difference

by

Is systems thinking really possible? Here’s one reason why it might not be.

One of the concerns of systems thinking is the need to avoid the so-called environmental fallacy – the blunder of ignoring or not understanding the effects of the environment of a system. This is why, when systems thinkers are asked to tackle a concrete situation in detail, they often hesitate, insisting that it is wrong to look at the detail before understanding the context.

The trouble with this is that there is always a larger context, so this hesitation leads to an infinite regress and inability to formulate practical inroads into a complex situation. Many years ago, I read a brilliant essay by J.P. Eberhard called “We Ought to Know the Difference”, which contains a widely quoted example of a doorknob. As I recall, Eberhard’s central question is a practical one – how do we know when to expand the scope of the problem, and how do we know when to stop.

C West Churchman went more deeply into this question. In his book The Systems Approach and its Enemies (1979), he presents an ironic picture of the systems thinker as hero.

If the intellect is to engage in the heroic adventure of securing improvement in the human condition, it cannot rely on “approaches,” like politics and morality, which attempt to tackle problems head-on, within the narrow scope. Attempts to address problems in such a manner simply lead to other problems, to an amplification of difficulty away from real improvement. Thus the key to success in the hero’s attempt seems to be comprehensiveness. Never allow the temptation to be clear, or to use reliable data, or to “come up to the standards of excellence,” divert you from the relevant, even though the relevant may be elusive, weakly supported by data, and requiring loose methods.

Like Eberhard, Churchman seeks to reconcile the heroic stance of the systems thinker with the practical stance of other approaches. But we ought to know the difference.

This is an extract from my eBook on Next Practice Enterprise Architecture. Draft available from LeanPub.

John P. Eberhard, “We Ought to Know the Difference,” Emerging Methods in Environmental Design and Planning, Gary T. Moore, ed. (MIT Press, 1970) pp 364-365

See extract here – The Warning of the Doorknob. The same extract can be found in many places, including Ed Yourdon’s Modern Structured Analysis (first published 1989).

See also

Nicholas Berente, C West Churchman: Champion of the Systems Approach

Jeff Lindsay, Avoiding environmental fallacy with systems thinking (December 2012)

Updated May 14 2013