Monthly Archives: January 2011

ArchiMate, BPMN and UML together

The question about “the remaining role of UML now that ArchiMate has arrived” generated an interesting discussion on the ArchiMate LinkedIn group. Adrian Champbell‘s first comment was:

Archimate was deliberately designed to be mappable to BPMN and UML, but not to replace them. Not parallel universes but complementary ones.

Archimate is for modelling at an Enterprise Architecture level of detail and not at the Solution Architecture and Software development level of detail. BPMN and UML have much more detail in them than ArchiMate.
Conversely neither BPMN or UML can replace ArchiMate either.

I agree with Adrian. Actually, I find the idea of an EA notation set comprising ArchiMate, BPMN and UML quite appealing. They are complimentary, although having some representation types that could be redundant in a unified method.  I use  ‘representation type’ here to avoid ‘model’, which means different things in UML and ArchiMate. There are other fundamental differences, but we don’t have to deal with all of them. The three notations can co-exist quite well as they are. Especially when supported by a repository-based tool with decoupled content and presentation layer. It seems that what is needed in a wide variety of use cases is already there; when not, an extension could take care of it. The rationale behind such a combination of ArchiMate, BPMN and UML  is to have a relatively small number of notations that could satisfy most stakeholders and comply with some common modelling rules. Finding a good way to integrate these three languages could bring many benefits. Coming to one universal notation turned out to be a difficult task, maintaining a dozen is neither efficient nor effective and then having several kept separated, used per project, could bring little benefit for the enterprise in the long run. Then how about these three only, and well integrated?

There are two basic questions. How to make them play together? How to add what is missing?

To make them play together

we need some mechanisms and some rules. We need mechanisms for transclusion, elaboration/navigation and transformation. We also need rules to avoid redundancies and ambiguities.

Transclusion or a similar mechanism is needed to manage separated content and presentation spaces. This should enable some unit of behaviour, for example, maintained in the content space, to participate as a task in a BPMN diagram, a process in ArchiMate view, and an activity in UML Activity Diagram.

An elaboration/navigation mechanism is needed to link, for example, a process in ArchiMate with its BPMN elaboration and data object with its elaboration as UML Class Diagram.

Transformations could be handy in cases where we need to generate a UML Sequence Diagram from BPMN Collaboration Diagram. Such a demand may arise when at some point, we need special message capabilities like create and destroy and/or we need to see when objects are active and when passive which would be a bit of a challenge for a pool to show.

Modelling rules, along with method restrictions, should be used to avoid redundancies and ambiguities. The diagram below shows some overlapping areas. It should be clear, for example (area 1), when a process should be represented as ArchiMate process view, when as a BPMN process diagram or UML Activity Diagram, if ever. It seems natural to expect ArchiMate process view to be used for more conceptual representation and then each process to be elaborated as BPMN process or collaboration Diagram (Area 2). A similar convention could be applied to data structures in area (3). In many cases, UML Class Diagrams are used without specifying attributes and methods. Probably in those, an ArchiMate data view should be more appropriate as then the same data objects could easily be reused in coherence views to show relations with a service, for example.

The main idea behind BPMN is to bring processes easily to process engines for execution. As smooth as possible. How successful in that is the recently released BPMN2 is another question. I’m not going to discuss it here. Just want to draw your attention to area (5). There are some cases where it would make sense to elaborate a Service Task from a BPMN diagram to a UML (component) diagram.

To add what is missing

we need some extensions. I mentioned a few things missing for a whole-of-enterprise EA in my previous post. Most of those should clearly extend ArchiMate, assuming we confine to this trilingual framework. What I see as the most ‘urgent’ need is for a motivation extension. So far, there is one good attempt to satisfy it. Still a lot to improve, but the first step is made.

Another extension could meet the demand for a loose sticky-notes type of modelling. It brings people together and smulates creativity and innovation. There are already some good methods for that, such as the Business Model Canvas. It would be even better to have the freedom for brainstorming and collaboration and then some way to transform ideas into a more rigorous model. I find the whiteboard in ARIS Align a very good example. There, in a collaboration environment,  sticky-notes from the whiteboard could be dragged and dropped as tasks in a method-restricted area for business process modelling. How about a similar thing with business models done using business model canvas? Just drag the sticky note and place it in the ArchiMate ‘area’ to create an object. A sticky note from the Value Proposition building block would probably be transformed into a Business Service or Product in ArchiMate. Well, as often happens, a notations talk easily slips into a tools-and-features talk. Not good, but since we crossed that line, let’s mention another feature. A toolset supporting the integrated use of these three notations should always have a way to support an author-specified notation. Alternatively, some abstract diagrams, like context-space maps or the one above, should be done outside.

Realization

We represent aspects of (or decisions about) reality to help us improve it. The bottom box in the diagram is labelled ‘realization’. I didn’t want to call it execution or automation. Our subsequent decisions could be realised with or without IT. That brings us to the fourth arrow on the right side. Some decisions represented in ArchiMate could be realised as changes in enterprise reality with no use of IT. Others can make use of IT or affect IT but without any need to go through BPMN or UML.

These were just a few thoughts on the idea of an EA notation set comprising ArchiMate, BPMN and UML. Only user experience could show if and how that works. There are companies using ArchiMate and UML together, the latter to support Solution Architecture modelling. Others use BPMN and UML. Maybe there are some that have already experienced or probably standardised on the three.

All-inclusive Enterprise Architecture

That’s not the most appropriate title. My intention is not to dub another type of Enterprise Architecture, and least of all one that sounds like a holiday package. That would defy the points I’m trying to make. Yet I couldn’t help it. The concept of Enterprise Architecture (EA) as I understand it – and luckily I’m not alone – is all-inclusive by definition. It doesn’t mean EA should include everything, just those things that are important for the enterprise and can be supported by EA management. Some of them are currently missing.

The reason we need EA, according to TOGAF, is to support “delivery of business strategy”. But after that line, all listed benefits are solely around IT. The rest of TOGAF and most of the other frameworks are IT-centric as well, though admittedly business conscious. Of course, they should be business conscious. Just remember what the driver that brought EA into existence: the gap between business and IT. But it seems the current EA practice is too short a bridge which is now falling down that same gap instead of bridging it. Why? Because it’s not enough “IT” to deliver tangible value and it’s not enough “Business” to make business people interested. No wonder BPM for example is doing much better on its own (How we came to have EA and BPM as separate disciplines will be the topic of another post). Not that the “B” in BPM is what it should be. Yet, the interest in BPM is growing while in EA is declining, or – to use the Gartner terminology – EA enters trough of disillusionment.

If on the other hand, EA was really business driven, not just business conscious, then we should have seen it already in the MBA curricula together with Finance, Marketing, Management and probably right after

Strategy

There seems to be a broad consensus around EA being a strategic enabler. Gartner defines EA as “the process of translating business vision and strategy into effective organizational change”. But then strategy is hardly anywhere in the frameworks and unfortunately not much in the EA practice. TOGAF does not provide any way of seeing how EA supports the delivery of business strategy. Actually, motivation concepts were entirely missing until recently. What appeared in version 9 was a motivation extension in the content framework timidly featuring driver, goal and objective. It’s difficult to understand why motivation should be an extension and not a core concept. Shouldn’t it all be derived from there? Other frameworks seem to be doing a bit better in that respect. For DoDAF the concepts of capabilities, measures, and goals (desired effects) play a central role in the meta-model, and they are well integrated with the enablers – services, activities, people and systems. FEAF in its Performance Reference Model has clarity about value creation from inputs (people, technology, and other fixed assets) through outputs (processes and activities) to outcomes (mission, business and customer results).

There were more efforts in this direction in recent years. And some good results. Notably, one of them is the Enterprise Business Motivation Model of Nick Malik which extended the BMM of OMG, developed by Business Rules Group.

Some good news is also coming from the notations front. A very promising extension of ArchiMate was proposed to fill the motivation gap in the notation and achieve better traceability of requirements. Having motivation in, it’s mostly used to achieve traceability, to have the “why”-chain from the system we implement to what the ultimate business goal that it’s meant to support. Good, but is it good enough? And then, when we need to find that strategic goal, we usually search in the strategic plan. But are all strategies planned? How about “emergent” strategies as Henry Mintzberg called them back in the early 90s. Don’t we see more of those recently? Strategies that emerge from the user experience. Here, user experience. How about that in EA? Or brands? Or probably their place is not in EA. In 2009 Google market value was estimated around $108 billion and the value of its brand over $100 billion. The brand value of most companies in that same list is over 90% of their market value. Do we want to have EA which excludes 90% of the company?

EA needs a strategy to direct its change and strategy needs EA to make things happen. And not only for that. The strategy needs architecture for its own design to improve its communication and execution control. After all, it was the advent of strategy maps that turned the Balanced Scorecard from an original idea to worldwide adoption.

Structures

Another general consensus probably first articulated by Peter Drucker is

Structure must follow strategy

Which structures? Scope-wise, here’s where contemporary EA is quite often organisation-centric. EA is about processes, systems and technology. About processes within organisational boundaries. That’s why the real architects of the enterprise, the CEOs, are sceptical about EA value proposition. Because for them

the customer has the process. We have to decide how we want to appear in that process – what we want to contribute to the customer experience – and make sure that’s what our day-to day performance actually achieves

From recrEAtion by Chris Potts

Content-wise, we don’t see EA focusing much on structures for non-IT related initiatives. Like for example cost analysis. It’s not new that the actual product and service cost is hidden in the process and cost centre structures. That’s why when bigger and bigger part of the product costs went into the overheads, activity-based costing (ABC) came into the game. EA methods and tools could be an indispensable instrument not only for ABC analysis but way beyond that. And certainly beyond technology cost optimisation. But OK, let’ have a look now at

Technology

I’ve seen many enterprise architecture descriptions. In all of them, it seems that the enterprise has only one type of technology – IT. Yes, that’s of primary importance in the service industry. But that’s not the only type. And then, even in cases where investments of non-IT technologies are times bigger than those in IT, those other technologies are entirely missing in the EA blueprints.  Why should you believe in enterprise-level description that is so different from what you read on the balance sheet?

Enterprise Architecture is indeed currently in the “trough of disillusionment”. Yet, it brings a lot of value even as it is. But it can do much better. And it should if it is to get out of the trough. One idea is not to leave out things such as strategy, brand, user experience, knowledge, trust, non-IT technologies. They need EA and EA needs them.