#eavoices

EA Food Chain – Enterprise Architecture from Business Strategy to Operating Systems

by

Hard to add to the self explanatory picture above! Even though I am a technologist at heart, the discerning reader will surely appreciate the hogging of real estate by the word “Business”. After all, that is what it is all about.But please, please, ple…

What really matters

by

I planned for quite a while to write a post (or series of posts to be accurate) but there was always something distracting me. Well, that happens, so no worries. Yesterday and the day before I have been on the Gartner EA Summit which was truly great and enlightening in many different ways, despite my incapability to plan a bit ahead. When I left the hotel today 5:00 in the morning to catch the first flight home I truly planned to write about it, more than one post actually. But then something was brought to my intention, something what really matters. (I might though come back to the Gartner EA Summit and what I learned later).

The flight went fine and I got picked up as planned by the taxi. Perfect service by the way including Internet access and bottled water to drink. As always the travel went smooth and perfect, so I could work my way through a stockpile of email to put some things into context, sort one or the other topic. Basically normal travel type of work. But then, something was brought to my intention. Heavy impact actually.

  1. All of a sudden the driver had to go into the breaks, not really, but strong enough for me to recognize, so I looked up to see whats up and of course the classical motorway road works traffic jam.
  2. I heard some breaks, but nothing really worrying and then suddenly the driver was taking his hands away from the steering wheel and in that very same moment a large truck was blowing his horn and then the noise of metal, plastics and humans screaming.
  3. Something bumped also in the car I was sitting in (normally I was sitting always on the front seat, but this time I was sitting in the back to work) and a giant truck was sledging diagonal from the back into my sight field and into the farming field next to the roadway.
  4. [total silence]
  5. The driver of the truck left his truck within 10 seconds as far as I was able to recognize unharmed and the driver of the taxi I was sitting in just drove 20 meter forward to secure a way for potential emergency cars.
  6. Then we left the car, and it was a field of demolition. Apparently a second truck was standing on the emergency lane obviously heavily hit by something in the rear. A small bus for 8 persons was wrecked and standing on his wheels but into the wrong direction (later my driver told me that he has seen that bus doing a rollover), 2 cars have been hit heavily (airbags executed) and bumped into the cars in front of them, one of them obviously hitting us.

Our car and another car almost unharmed, just small scratches in the rear, but have a look at the red truck who litereally was flying in as my driver told me on the rest of the travel more than once.

  1. Almost at the very moment 4 people from Johanniter Unfallhilfe came running. I was truly impressed, but in reality it was just luck that they have been driving a couple of cars behind us. So the professionals could take over and did that really great. It was very fast clear that noone was harmed heavily. Everyone involved could walk, talk and was cleary able to response reasonable (despite some really shaking knees and white faces).
  2. Shortly afterwards police officers came to secure the area and a helicopter flew in. Impressive speed by the way, I haven’t clocked it, but it for sure was well below 10 minutes till the helicopter with the doctor was there.
  3. The volunteer fireworkers from that area also arrived with quite some vessels and people.
  4. What was obvious in that realm of chaos was high professionalism, but also quite some communication and handovers. From Johanniter to police to doctors to fireworkers. The cars were triple checked (Johanniter, Policemen, Fireworkers) All of the involved professionals spoke to the people involved in the accident, quite some confusion about many things for example insurance (how irrelevant at THAT moment, yet important for some. As far as I recognized it, that insurance concept was at least one thing people understood in that moment).
  5. They collected all of us and explained the steps and there was a fairly good atmosphere, because everyone was well aware that things could have been way worse. Personal data was recorded by the police people, the doctors did a short examination and send those from the more heavily impacted cars into hospital, the fireworkers cleaned the street to allow the emergency cars to drive through, lots of pictures were made.
  6. Not that I want to make that experience again or wish that anyone, but it was brilliant to see them in action, coming from knowing nothing to full control of the situation in less then 15 minutes.
 
Given all what I learned at the Gartner EA Summit (and other events), why can that story not be told different?
 
  1. Preventive
    1. A Traffic Jam is signalled back to the following cars (and to traffic control) and warns the drivers (like red alarm in Star Trek if you want) or even better forces the car to slow down, no matter what the driver believes.
    2. A car in trouble signals to the other cars (and traffic control) that it is in trouble.
    3. Cars are forced to have a relevant safety distance.
    4. Cars are forced to not overspeed (yes, there will be people who believe this should not be done, but in that case it would have helped a lot and under worse circumstances it would have saved life).
  2. Impact
    1. On an impact the car or environment is signalling to other cars as well as to traffic control.
    2. Traffic control sends a drone to examine the area and create a 3D model.
    3. That 3D model gets send to all potentially involved parties which can use it to plan the operation while already driving to location.
    4. Each unit supported by augmented reality updates new information real time into that model, so that everyone involved has the full picture and can therefore act acordingly, e.g. more people, specialized vessels, specialized skills, but also retreat if the impact was less harmful than thought. There could be way more parties involved than in this particular case.
  3. Afterwards
    1. All the information can be directly fed into the system including the 3D model for reports, insurance, news, whatsoever.
So thank you consumer market for bringing us all these great new potential, but it is only interesting. Relevant is something else, nevertheless, please explore more, because it might be useful somewhere else. Truly relevant. Over to you.
 
P.S.: This was just a quick writing, the accident is less than 8 hours ago and I was doing quite some other things in between, but I believe there could be many stories created out of this and potentially there are already units in the world building this system so that it is usable, easy to use and as cheap as possible. I can only hope for that.

June 2013 Events

by

One seminar (free) and several workshops (pay).Perspectives on Enterprise Architecture and Systems Thinking (EAST)14 June 2013, Central LondonThe meeting is intended for experienced practitioners of Enterprise Architecture (EA) and/or Systems Thinkin…

Enterprise Architecture Fatigue

by

Enterprise Architecture FatigueInteresting discourse with a new client. They have been through numerous attempts to establish Governance using Enterprise Architecture and every time they find themselves swamped with extremely clever people who produce …

Marketecture – a technique every architect should learn

by

One of the drivers for me to develop the content in my book “Stories that Move Mountains” was the development of many different ‘marketectures’ to help market the ideas in a new architecture. This idea resurfaced in a recent posting from Cutter.

 

http://blog.cutter.com/2013/04/09/marketects-delivering-good-enterprise-architecture/?utm_source=rss&utm_medium=rss&utm_campaign=marketects-delivering-good-enterprise-architecture​

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.