business-arch Archives - Agile Enterprise Architecture

Example Services and Capabilities with Meta-Model

2014-11-092018-05-08
by Charles

Introduction

This blog on Services and Capabilities came out of thinking about a few related subjects:

1. How to use Archimate to model Capabilities as this is not directly supported in Archimate terminology.

2. On how Services relate to Capabilities. These seems to be a lot of discussion about this on the EA forums.

3. How all of the above should all be modeled in an Enterprise Architecture Model using any tool that supports Archimate.

4. How Architects who model hierarchical nested diagrams of one type (e.g. Application services) can see how this would still be possible.

So I thought the best way of explaining how I believe it should be modeled was to model one example situation in each domain for the following:

1. The Business domain – Business Service & capability – Route Planning example

2. The Application Domain – Application Service & capability – that supports Route Planning example

3. The ICT Domain – ICT Service & capability – the Database service that supports the above two.

Enterprise Service Model

So below is the Enterprise Service Model. It shows the typical structure of a whole Enterprise Services model. The services on this diagram (shown in green) give you one Business Service, one Application Service and one ICT Service; one service from each domain. On it I have only shown what has been modeled in the separate Models / diagrams in the sections below as well as any ‘used by’ services or ‘related’ showing service dependencies.

Route Planning – Business Service & Capability Example

This model below is the Business Service and related Capability to support the ‘Route Planning’. Route planning comes from the notion of a travel agency establishing tailored itineraries for prospective customers. As you can see the Capability is shown as a ‘Business Interaction’ and is a collection of Roles, Actors, Processes, Artefacts, Locations and events, that all make up the Capability. The Business Service also depends in a large part on some Application Services.

Route Planning – Application Service & Capability Example

The Route Planning Application Service is shown here in more detail. It shows the Application Services with it various Application Interfaces (some System/Machine and some Human). It then shows the Application Capability, again using an Application Interaction as the wrapper for all items that make up the capability, such as locations, Application Collaborations and Application Components. Each of these elements relies on ICT Services such as servers, desktops and other technology.

Database Server (for Route Planning DB) service – ICT Service & Capability Example

This is one Service of many that support the Application Service and its Capability elements. Again following the pattern of a Service having an Infrastructure interface and saying what should be done not how it should be done. The Capability expands on the detail of how it is realised. This is where I felt there should possibly be the same notion of an Infrastructure Interaction entity but Archimate does not seem to support that. This model also shows how the layers above it interact with the ICT Service, e.g. that the DB SQL Server (software) service relies on a DB Server (O/S & hardware) service.

Meta-Model that brings it all together

While not wanting to re-invent the Archimate Meta-Model, I wanted to show the groups, and inter-relationship that this would build up in an EA Model of the organisation if we were using a tool to support this. The top part is the Portfolio and Programme office controlling the work-packages to do a transformation. They would need to understand the As-is and various Tranches of work per gap to get to a To-Be state. This they would primarily do of the higher level services, but could also go down to more detailed Capabilities to see the deltas between the various as-is and to-be plateaus.

Other Model Views

It seems to me that many EA initiatives love to show the breakdown hierarchically of one Architecture building block type, e.g. Principles, or Organisational Business units, Services, etc. in isolation. I wanted to show by doing the above that all this information would be gathered in any case by working to build up these models. They would just be a by-product of gathering the above information.

The real value is to be derived from the interconnections and relationships in the meta-model of all of these elements below, including the entity instances themselves so that we always know what our inventory of them is so as not to forget things in doing analysis. The impact and dependency analysis is only obtained by connecting up the relationships between entities, provided it is done at a course grained enough level and we don’t try and model the whole world in great detail.

Enterprise Architecture

Who should own Enterprise Architecture?

2009-03-282018-05-08
by Charles

The clue about Enterprise Architecture ownership is in the title. One of the issues I see as an EA practitioner all the time is the fact that Enterprise Architecture typically falls within the IS/IT Department remit within many enterprise organizational structures and not where I believe it ought to be positioned. EA should be part of the Strategy Department under the CEO and therefore divorced from either the Supply or Demand side of the Enterprise, thereby governing from a neutral position and informing the executives of the enterprise. EA positioned within IS/IT it’s like having two opposing Lawyers in a court room where one of them is also acting as the Judge; the verdict is always only going to go one way.

Why is EA in IS/IT mostly? The reasons for the evolution of EA being owned within the IS/IT department are quite understandable. The practice of Engineering and Architecting systems and systems-of-systems stems primarily from the Technical domain rather than the Business domain, out of a need to build and supply rigorous software and hardware systems.

The business domain have used simpler diagrams to show concepts, to collaborate on ideas and thoughts, but till more recently the business have never had to be very rigorous other than in the financial sense. More recently the business domain is dealing with more formal business processes diagrams that generate working software, so the rigour is beginning, and so too is the understanding.

Whereas the Technical domain has relied on a far more rigorous diagramming notation to formally build and help implement systems. Architecture does not stop at diagrams; Requirements have to be formally managed and traced, Configurations of systems have to be managed, Change controls have to be managed, Testing, Hardware connectivity for LANs and WANs have to be formally managed, etc.

The common currency between the Supply and Demand has been money, time and power. All discussions have come down to the first two with the third making the final call. These are only the tip of the iceberg. Unfortunately none of these involve complexity and the buildup of “Enterprise Technical Debt“.

Hence the practice of building up Architectures and being able to Govern and manage complex systems has mostly evolved from the Engineering side. The Technologists have understood why this is important to them. They have built mechanisms to cope with complexity such as Abstractions, Visual Modelling, Configuration and Change Control management systems, Reusability, Services, Test, Build and Deployment automation, etc.

So with this in mind, if you look at an Enterprise from a Supply and Demand point of view, in general Business drive the Demand and Technology Supplies the solutions. On the demand side you would expect to see motivation, direction setting and strategy, which ties into the time and money available.

On the Supply side you’d expect to see a reply to that Demand given certain principles and constraints such as ensuring re-use, avoiding duplication of resources in terms of Servers, Data, Functionality, etc.

Put all this into a negotiation between Demand and Supply and somehow out of all of it, certain compromises get made on both sides.

Generally Business give up functionality and Technology gives up coherent Architecture. In order to control and regulate these conflicts of interest IS / IT departments have implemented Governance processes, at various levels, Programme and Project, Architecture, Service management, etc.

The challenge is that as the ever technically savvy Business submit Demands on the Technology Supply side, how can IS/IT possibly govern these compromises if they are not empowered to straddle both sides of the debate? An IS/IT based Architecture governance is not in a position to rule against the Business, particularly if the Business hold the purse strings and are the Demand “Customer”.

Consequently IS/IT want to make themselves look good by trying to deliver on time and within budget, and start compromising on their own principles by ignoring the Architecture governance outcomes, or offering endless Waivers and Dispensations. Many Supply side Risks and Issues are never feedback into the Business on the demand side, and even if they are fed back, many times it’s too late or the business cannot interpret the meaning. Ultimately the Enterprise is compromised over time. The Enterprise Technical Debt builds up and builds up until all ability to make any change at all becomes impossible. Any change costs too much or takes too long. All Agility is lost.

Instead if a small Enterprise Architecture team of practitioners made up of Business Architect(s), Information Systems Architect(s) and technology Architect(s) are put into a “Strategy” team under the CEO, who liaise closely with the IT Solution Architecture team, and the Business subject experts then, the equilibrium should be restored. The IT Solution Architects should still remain under the CIO and not directly report to the “Strategy” (or some more meaningfully named) EA team. This assumes a lot of collaboration, communication and engagement between all parties. The “Strategy” EA team should have the necessary technical and business background to feedback the overall Risks in the business and thereby avoid the inevitable Enterprise Technical Debt build up over time.

AgileEA Process

Putting the Agile into an EA process (2007)

2008-07-252018-05-08
by Charles

Abstract

In March 2007 Charles delivered his first talk about the Agile EA operational process at the Togaf Conference in Cape Town South Africa. Read up on the content here:

http://www.opengroup.org/capetown2007

http://www.opengroup.org/capetown2007/edwards.html

Download

pw2007-Togaf-PuttingThe’Agile’IntoAnEAProcess-V1.1.pdf

Enterprise Architecture

The Enterprise Architecture Vacuum

2008-08-292018-05-08
by Charles

Abstract

There is an Enterprise Architecture Vacuum. Architecture in computing and business is an often misunderstood concept. Many of those who work in Information Systems and Technology Departments do not necessarily come from a software or systems architecting and engineering (specifically coding) background. They find it difficult to fully appreciate many of the subtleties of Architecture because they do not have a Modelling or Systems thinking background.

This paper shows how due to misunderstanding the breadth and depth of the various architectural concepts it is easy to overlook a fundamentally important and strategic part of the Enterprise as a whole; in particular Enterprise Architecture.

Download

Version 0.04 can be downloaded here: Enterprise Architecture Vacuum-V0.04.pdf

Strategy

EA strategy maturity (2008)

2008-10-052018-05-03
by Charles

I was recently asked to review an IT Strategy document and give my views on it. This document did not appear to come from what I would have called an Enterprise Architecture practice but from a typical IT approach to strategising about how to deal with all the technology in the IT department.

Before starting I thought to myself, what standard should I score this against? This then lead me to think about different levels of Maturity of Strategy implementations (in this case an IT strategy), but it could be used for any strategy I suppose.

Basing my thoughts on the CMM definition I came up with this table below in terms of the levels of sustainability, repeatability and continuous optimization of Strategy:

Level	Conscious	Planned	Governed	Quantitative	Continuous	Description
0	No	No	No	No	No	Chaotic – Unconscious of Strategy
1	Yes	No	No	No	No	Initial – Cognitive Strategy
2	Yes	Yes	No	No	No	Managed / Planned Strategy
3	Yes	Yes	Yes	No	No	Defined and Governed Strategy
4	Yes	Yes	Yes	Yes	No	Quantitatively Managed Strategy
5	Yes	Yes	Yes	Yes	Yes	Continuous Optimizing Strategy

So level 0 is where there is zero concept of any strategy. The organisation just muddles on, project by project, request after request – firefighting.

Level 1 has a cognitive concept that strategy is important and tries to implement it from a mental model, and give direction in conversation to people, but no more. This tends to come from someone leading but is perhaps not general knowledge in the department.

Level 2 is where a plan has been derived and planned, based upon gathering information in some one-off exercise. This is typically put together for the budget in order to justify funding for the next year or three. Thereafter it is cast aside, once the money has been obtained and the projects have been defined.

Level 3 takes this to the next level, because not only is it planned but over time, it is managed and governed, to ensure this strategic plan actually happens. The reason this has been differentiated as a separate item is because in my humble experience, many of the best laid plans fall away after a few months, as people change positions or business changes occur. Eventually the initial strategy is forgotten, and things devolve into firefighting again unless governed against a baseline. Obviously this does not imply that the baseline cannot change, in fact it will change, but if a new baseline is derived then the governance can continue to monitor progress against the new strategic baseline.

Level 4 goes up another notch by measuring the Strategic Architectural goals met against the initial plan versus the actual delivery. Even if Waivers and Dispensations are given, and these are measured, we have an adea of convergence or otherwise towards the strategy. Capturing daily, weekly and monthly Architecture review board activity metrics, and reporting them regularly over time. This also begins to imply that the Strategy is captured and managed as well, because if things change, we need to record the differences from the initial baseline to the new baselines over time of the Architecture.

Level 5 is where the Strategy evolves continuously, due to the above processes of monitoring, persisting the information and governing the change in a managed way on a regular (weekly to monthly) basis. Weekly. Eventually we reach the situation where it would not be necessary to do a one-off Strategy once per annum for the budgets, but to do one and keep continually refining it and governing it. When budgets are submitted, it is a simple matter of printing out a few diagrams and reports from the decision support system that already exist, ordered by highest risk and current business drivers.

All this would require a foundational set of configuration management, change management and iterative planning to keep on top of the “Models” be they visual or otherwise that make up the Strategy.

Based upon this maturity – the document and it’s contents I saw reached somewhere between 2 and 3, but I was not privy to how they would manage or govern it so I could not say for sure, as its not only about the actual document, but also about how we manage the Strategy over time that makes it more mature.