Is Archimate too IT-centric for enterprise-architecture?
Archimate aims to be the standard notation for enterprise-architectures. But has it become too IT-centric to be usable for that purpose? And is there any way we can get it to break out of the IT-centric box?
These questions came up for me whilst exploring the architectural processes we could use in expanding a business-model developed in Business Model Canvas out into the detail needed for real-world implementation. Archimate should be the obvious standard to use in describing an overall architecture: but at present it’s not so much IT-oriented as almost entirely IT-centric, and a real-world business-model involves a lot more than just IT. Yet if the only available standard only describes the IT, what on earth can we use to describe everything else? And how can we link everything else back to the IT? Therein lies the problem.
Let’s step back a bit. More like a decade, actually.
Archimate started out as means to solve some real architectural problems for users of large IT-systems in the Netherlands. A consortium of academics, IT-consultancies, business-users and government was brought together, to address how to link all the different layers of the IT-domains together, from the business needs, down through the IT-applications and data, all the way to the actual IT-infrastructure that supported all of those needs. In other words, the usual IT-oriented layering that we see in TOGAF and so many other ‘enterprise’-architecture frameworks.
That kind of layering does make perfect sense if the focus of concern is IT, and if the business of the business revolves primarily around information. In other words, it fits well with IT-architectures for information-centric businesses such as banking, finance, insurance and tax – hence the reason why the usual Archimate ‘demonstrator’ is an imaginary insurance-company called ‘Archisurance’.
But this doesn’t make sense – or rather, is far too constrained and constraining – if the focus of concern is anything other than IT, or for any type of business whose business is not centred solely around information. Which latter, in reality, is the case for most businesses – if not all of them, once we start looking at the deeper detail of most business-models.
Which means that, for those of us involved in real enterprise-scope architecture, business-architecture, security-architecture, process-architecture, or any kind of architecture that touches just about anything other than IT, we have a problem here. A big problem.
A problem which in some ways is actually getting worse.
Which means it’s a problem that, collectively, we need to do something about, right now. Urgently.
Why do I say it’s getting worse? Well, take a look at this section from Chapter 2 of the original Archimate Primer [PDF], from back in 2004:
In the enterprise-architecture modelling language that we propose, the service concept plays a central role. A service is defined as a unit of functionality that some entity (e.g. a system, organisation or department) makes available to its environment, and which has some value for certain entities in the environment.
It’s clear that ‘service’ here is intended to be generic – not solely IT. And service-orientation is a certainly good place to start for whole-enterprise architectures.
The chapter-text continues with a brief summary of that all-too-common IT-oriented layering of ‘Business’, ‘Application’ and ‘Technology’. The accompanying diagram and text, though, do make it clear that there’s more to the context than IT alone, and that we do need to take the broader enterprise into account, beyond just the organisation itself:
The Business layer offers products and services to external customers, which are realised in the organisation by business processes performed by business actors. … On top of the Business layer, a separate Environment layer may be added, modelling the external customers that make use of the services of the organisation (although these may also be considered part of the Business layer).
So far, so good. It’s about services, and about the broader enterprise; it’s IT-oriented, but not IT-centric as such.
Yet somewhere, things started to go badly wrong, from an enterprise-architecture perspective.
Somewhen around 2008 or so, with the aim of making the still-somewhat-prototype standard more available worldwide, Archimate was transferred to the ownership and aegis of the Open Group. That move no doubt seemed sensible enough at the time: but the problem is that the Open Group is an IT-standards body, not an architecture body – and that built-in orientation towards IT starts to show even in the very first sentence of the Archimate version 1.0 formal standard, published in 2009:
An architecture is typically developed because key people have concerns that need to be addressed by the business and IT systems within the organization.
And by the time we reach the standard’s chapter on Enterprise Architecture, that all-too-common IT-centrism is in full flood:
The primary reason for developing an enterprise architecture is to support the business by providing the fundamental technology and process structure for an IT strategy. Further, it details the structure and relationships of the enterprise, its business models, the way an organization will work, and how and in what way information, information systems, and technology will support the organization’s business objectives and goals. This makes IT a responsive asset for a successful modern business strategy.
Today’s CEOs know that the effective management and exploitation of information through IT is the key to business success, and the indispensable means to achieving competitive advantage. An enterprise architecture addresses this need, by providing a strategic context for the evolution of the IT system in response to the constantly changing needs of the business environment.
You could just about get away with that kind of myopia in 2009, though even then its absurdity was beginning to be more widely recognised. Two years later, it’s probable that most members of Open Group would acknowledge that there are some serious limitations there, and many – such as Len Fehskens and Microsoft’s Mike Walker – are much more overt in asserting the need to break out of the IT-centric box.
In short, we need an Archimate for enterprise-architecture – not just IT-architecture. We need – and need urgently – an Archimate that isn’t all-but-uselessly IT-centric.
And yes, the good news is that a new version of the Archimate standard is due for release Real Soon Now. Hooray!
The bad news is that this new version isn’t likely to help much at all. If anything, it’s likely to make it worse…
I’m not a member of the Open Group or the Archimate forum, so I’m not directly involved in the update. But from what I hear from colleagues who are involved, the new version will be just as IT-centric as the old one. That text above apparently remains completely unchanged in the new standard: which means that its definition of ‘enterprise’-architecture is not so much out of date as just plain wrong. I’m told there are a couple of new sections to the metamodel: one is on motivation, to sort-of link it to the well-known Business Motivation Model; the other is about projects and dynamics, linking to and in some ways improving on the TOGAF 9 metamodel. I gather that there are a few new generic entities, such as Location, which would be not so much useful as essential. And Product, which used to be defined as “a coherent collection of services, accompanied by a contract/set of agreements, which is offered as a whole to (internal or external) customers”, is now apparently defined in even more rigidly IT-centric terms, as something like “a collection of financial or information services, with a contract that gives the customer the right to use the associated services”. Which doesn’t leave any space for descriptions of physical product or service, or relationship-oriented services – which is what most businesses actually deliver.
In other words, fine for the relatively small subset of enterprise-architecture that focusses around IT, but almost useless for anything else.
Which is not good news for enterprise-architecture.
So what can we do about it?
One option, I suppose, is to yell loudly at Open Group, and try to make it evident even to the most IT-obsessed of their big-consultancy members that this is nowhere near good enough. Sadly, I don’t think that’s going to work… 🙁
Another might be to ask the original Archimate group – Telematica Instituut and others – to retrieve the standard from Open Group, so that we actually have a chance to make it work again. Sadly, I don’t think that’s going to happen either.
Another option might be to use the Profiles facility in Archimate to define a much broader metamodel, particularly around the physical and relational analogues to the information-space that IT partially covers. That at least is doable – but the problem is that without a standards-body to coordinate all the various needed extensions, we’ll soon have no standard at all. Not a standard that we could for interchange, anyway, and not one that we could get the vendors to standardise on, to at last enable us to move architecture-models between the various vendors’ toolsets. Yet it doesn’t seem to be in Open Group’s interest that this essential work takes place, and at present there’s no-one else to take on that role.
Which at present, and for the foreseeable future, leaves us without a notation/exchange standard that we can use for enterprise-architecture. Again. After all these years. Sigh…
Over to you, folks: any ideas for anything that can get us out of this metamodel mess?
Very nice post to which I fully agree. Being Dutch I am almost a bit ashamed of Archimate’s popularity. Like you wrote its original goal and purpose was fine, but pushing it now as “the” EA language of choice is ‘over the line’ for me. I guess the marketing machine is doing quite alright, support of The Open Group doesn’t hurt either (Dutch organizations now all want TOGAF 9 so why not adopt everything TOG prescribes), but the main reason for the popularity IMHO is that most (enterprise) architects are actually developers, designers, and other IT professionals who have their roots and interests in IT, who will always fancy metamodels, frameworks, step-by-step approaches, and silver bullets, and who strongly believe that you can manage the ‘business part’ by just adding a few layers and notations (a.k.a. business architecture). At least that it is the feeling I get based on working with and teaching a lot of architects in the Netherlands.
From the solutions you mention at the end of your post I agree that the last one has the largest chance of success, but I think we could also decide to just let this ‘IT enterprise architecture school’ be, and spend our energy on spreading the word on the broader and (as you state) better definition of EA and think of methods and techniques to give architects a concrete alternative to metamodels such as Archimate.
never understood why Archimate
Things are not as bad as they seem. Being closely involved in the development of ArchiMate v2.0, I can tell you that the offending chapter on EA (which was largely taken from TOGAF 8, btw), will probably be removed/replaced. Also, the definition of a product is not going to be changed in the way you cite. I don’t know where you got that from, it certainly isn’t in the current draft proposal (which has the same definition as before).
It is rather unfortunate that you voice such a strong opinion based on incorrect and incomplete information. I do share your concerns about the future of ArchiMate, though, and linking it more closely to business needs (which may not even be “business architecture”) is certainly one of the things I’m personally concerned with. At Novay (the former Telematica Institute), we are e.g. working on the relationship between the Business Model Canvas and ArchiMate, but that work is not yet mature enough to become part of the standard.
What may be more important for now is the new set of concepts for modelling requirements, goals, stakeholders etc., which will help to move ArchiMate more towards the business. I am confident that ArchiMate is taking steps in the right direction, although its links with TOGAF and the formal process of The Open Group do pose some limitations. That is the price we had to pay to make ArchiMate internationally accepted.
ArchiMate is well known as a notation. We have frameworks like TOGAF, DoDAF, FEAF etc and we have ArchiMate which is a notation, right? I do value ArchiMate as notation but not as much as I value the underlying concepts. And those make it more of a tool for producing tools for expressing, communicating, analysing and calculating structure and behaviour than just a set of symbols, connections and rules.
You are right, the ‘service’ is defined and used as something generic. It’s used to separate what’s valuable for an agent from the way that value is created. That’s quite in line with service principles of separation of concerns and loose coupling. And even goes one step ahead – one and the same thing is used for integration (of different domains for example) and separation. The concept for re-usability is itself being successfully re-used.
The next thing is that ArchiMate is based on the natural language. Following this you can express many things, not just the IT-plus-a-bit-of-business stuff that is currently included in the notation set. Probably nobody will at first understand what you say when it’s not in the ‘dictionary’ but those emergent patterns that work will be stabilised through broader usage. And those are the patterns that deserve to live anyway.
The other generic, non-IT concept is related to the way views are governed by selection, presentation, interaction and interpretation rules. I think those ideas were published back in 2003 (right, Mark?). Again a generic concept.
I understand why those three things are not in the focus for the specs as issued by The Open Group. They are fundamental by nature and as such ‘compete’ with some parts of TOGAF. I might be wrong, probably they are other reasons. I certainly hope so.
@Rik Farenhorst – Rik, I do take your point about giving up, writing the whole thing off, and somehow starting all over again. The problem is that we do need something that we can use as a notation/exchange standard that will adequately cover the whole-enterprise space. To be blunt, right now Archimate is not only the best hope we have, but probably the only hope we’re going to get in quite a while. It matters.
Also Archimate is darn good – a lot better than almost anything else that we have at present in the EA space. (Troux Semantics is a fairly good candidate for an alternative, but it doesn’t have the grasp of connection between things that Archimate has, and anyway it’s proprietary.) The real challenge with with Archimate is not that it’s ‘wrong’ – because it isn’t – but because it’s too constrained: it reinforces rather than reduces the ‘term-hijack’ of IT-centrism on EA, and from what I’ve seen/heard so far, I don’t think the new version will help much to resolve that. That’s my complaint here.
Would be good to talk further, about it, anyway.
@Marc Lankhorst – Hi Marc, many thanks indeed for taking me seriously in this 🙂 – because I’m well aware that you’ve been one of the leading figures in Archimate, and it was your Archimate Primer that I quoted (with much approval!) above.
I’ve looked again at the notes I was sent about the new version, and the comments about Product do seem to match very closely with the existing definition in version 1.0: it’s somewhat conflated, but the words do seem to match up exactly, though they do give a slightly different impression. The IT-centrism is certainly dominant in the description in v1.0, if not in the exact wording of the definition itself.
I can see how a linkage to Business Motivation Model would help, going ‘upward’ into more clarity in the business-space, and possibly ‘upward’ again into what you called ‘Environment’ in your Primer. (The very valuable diagram from Chapter 2 in the Primer that shows the relationship between ‘Business’ and ‘Environment’ is not present in the 1.0 specification, and – to me – its absence, and absence of anything else that describes that kind of broader scope, is one of the key drivers for the incipient IT-centrism of the spec.)
Biut ‘upward’ is not the real problem: it’s ‘downward’ that is the problem. To give one very simple example: if I’m modelling a logistics environment, how do I describe a physical parcel? – not the information about the parcel, but the parcel itself? Let’s say that I want to explore how the information about the parcel tracks the parcel, and what happens if/when the two don’t match up – which, as almost all of us know first-hand – does indeed happen in the real-world. How do I model that in Archimate? I can’t.
Sure, I can map the information easily enough, with a Business Object and a Data Object and Representation, and all the processes and applications and Devices and infrastructure that support that information – but not the parcel. I can say that the parcel is a Business Object – but then I’m stuck. I can’t describe any of the mechanical-handling equipment – the physical ‘applications’ and infrastructure – that act on that parcel. I can’t describe the fork-lift trucks and conveyor-belts and mail-trucks that move that parcel around. And so on, and so on: as soon as we try to map out a real business, we hit against the needs for all manner of descriptive entities that simply don’t exist in any form in the Archimate metamodel. So we’re stuck. We can either just ignore the whole ‘anything not-IT’ space and hope no-one notices it’s missing; or else kludge up various uncontrolled Profiles that will sort-of do the job, but are not compatible with anyone else’s because there’s no standards being applied. In short, it’s a mess. And we need a proper way out of this mess, urgently.
I’d be very interested to know where you’ve gotten to so far with the cross-mapping between Business Model Canvas and Archimate. From my side, I seem to have come quite a long way via using my Enterprise Canvas concept as an intermediate step, because of the latter’s explicit service-orientation. For example, the entity as a whole – the core section of the Business Model Canvas, excluding the Customer Segments and Key Partners – can be represented as an Archimate ‘Service’; each of the ‘child’ blocks within that core can be represented as an Archimate ‘Function’; each of the flows (‘before’, during’, ‘after’), that are only implied in BMCanvas but are explicit in Enterprise Canvas, can be modelled as an Archimate ‘Interface’, and so on. If we try to describe the complete business-model in the current Archimate, we hit up against exactly the problems I’ve summarised above: but once we do accept that it’s not Archimate as such that’s at fault, but the IT-centrism of the current spec, then it’s actually quite easy to resolve. Perhaps discuss ideas on this, anyway?
I hope it’s clear I’m not ‘attacking’ Archimate – I’m not. All I’m saying is that the IT-centrism of the current spec does place unnecessary and in some ways dangerously-restrictive constraints on its usability for any architectures beyond IT – which are becoming much more common now. The information I’d had indicated that other than the Motivation and Project extensions, the new version would be little changed, and that the existing IT-centrism would remain unchallenged: but I’d be very glad to hear that I’m wrong on that.
Many thanks again, anyway.
@Ivo Velitchkov – Ivo, you comment, “I do value ArchiMate as notation but not as much as I value the underlying concepts”: I strongly agree.
The crucial breakthrough that Archimate offers is that it pays as much attention to the ‘lines’ as to the ‘boxes’ – the entities and the connections between them. I don’t think anything else in EA offers that, and I literally do not see how to model an architecture properly without it.
TOGAF is, in essence, the ADM plus some useful guidance on what to do around and during the various phases of the ADM. Another way to put it is that it’s an architecture-oriented version of a Deming-style PDCA continuous-improvement cycle. It’s a good methodology for IT-architectures. The problems arise when people try to use it outside of that scope; or, for that matter, try to pretend that IT-architecture somehow ‘is’ the sum-total of enterprise-architecture – which it isn’t.
To me the TOGAF metamodel is one of those arbitrary add-ons that only exists because something needs to be in that space: most of the people involved would freely admit that it does need a lot more work to give it the kind of rigour and precision that it really needs. At present it’s a kind of uncomfortable mix of under-defined and over-defined – especially in the detail-layers, where at present only entities for IT-infrastructure are defined. I believe there was some hope that bringing the TOGAF and Archimate metamodels closer together would resolve this, but instead what we’ve ended up with is a reinforcement of TOGAF’s inherent IT-centrism – which isn’t all that much of a problem for the scope for which TOGAF was originally intended, but definitely is becoming a problem for the kind of architecture-work we’re seeing now. Hence the problems with trying to translate a complete business-model into Archimate notation.
My opinion is much the same as yours: we need to refocus on the principles that underly Archimate, and to some extent go back to square-one and redesign from scratch, working from the principles only, without any assumptions about implementation (which is how we ended up with the IT-centrism in the first place). As I see it, the core principles that we should keep are the distinctions between passive-structure, active-structure and behaviour; the general categories of entities; and the categories of inter-entity relationships (connections). I’m becoming more and more convinced that the current ‘layers’ concept – ‘Business’, ‘Applications’ and ‘Infrastructure’ – is a complete red-herring: they’re not ‘layers’ at all, they’re intersecting sets, all muddled together with things that really are layers in the Zachman sense and/or the service-decomposition sense, with everything conflated together in ways that are completely misleading. That’s the real source of the mess, and made worse again by the arbitrary constraints on scope applied as we go ‘downward’ through those layers. Once we scrap that pseudo-layering, then tease apart the real layering and set-intersections into a proper structure, I believe we’ll have a real chance to move forward.
The problem there is that we need a proper standards-body to supervise this, and I suspect rather strongly that Open Group is not the right standards-body to do it, because it requires a much broader scope than is in their remit. Probably the correct way to put it is that it really isn’t fair to ask them to do it, because it isn’t solely IT – and IT is, correctly, their world.
Where that leaves the rest of us, right now, I don’t really know. But that’s the point of asking this question, I guess?
Last year, I recommended TOGAF and ArchiMate as the core enterprise architecture paradigms for an organization that had heavily invested in business architecture, and considered enterprise architecture as a whole critical to its future. I am now involved in the evolution of the ArchiMate standard on behalf of that organization. Last year, I found that the combination of TOGAF and ArchiMate together comprised the only usable, general-purpose and non-proprietary combination of an ontology (conceptual system), a methodology and a visual modelling language (ArchiMate) that were all focused on enterprise architecture.
Since then, in conjunction with colleagues from a wide range of IT disciplines, I have found that ArchiMate 1.0 has useful and easily extensible semantics to incorporate business organization, role, service, capability, information and process modeling, along with all enabling technology. The layering mechanism is quite flexible, and can be altered or discarded as necessary per the extension guidance in the specification, or the more thorough guidance in Marc Lankhorst’s book. Since my initial recommendation, the organization has used ArchiMate very successfully in a number of projects involving changes in both business and technical architecture.
With the work being done on ArchiMate 2.0, the language will soon have the ability to model complex interplay between diverse stakeholders and their motivations, and to project and capture the progression of both business and technical architectures through complex and multi-threaded sequences of projects and programs.
While all standards and standards bodies have room for improvement, I am not aware of any other body besides the Open Group that is even attempting to provide an integrated comprehensive, and publicly available set of standards for the architecture of the large-scale socio-technical systems that we call enterprises. ArchiMate is far from a finished product, but serves many organizations well, and is in its early stages of development as a standard. I encourage those who see opportunities for improvement, even through radical change, to join the Open Group and participate actively in the ArchiMate Forum.
I hsve used a pseudonym to protect the organization with which I am working.
@An Enterprise Architect Hi AnEA – thanks for joining in.
I fear you may have missed the point somewhat here, and the key-phrase that indicates that is “in conjunction with colleagues from a wide range of IT disciplines”. No-one is doubting the value of Archimate and the TOGAF/Archimate combination for IT-architecture – that point has been explained and gone over several times above. But the point is that IT-architecture and enterprise-architecture are not one and the same – and the the belief that they are is what’s meant by the term ‘IT-centrism’.
It is utterly essential to understand that ‘business-architecture’ does not mean ‘anything not-IT that might affect IT’ – which in essence is how TOGAF treats that term. Despite the delusions of ‘techno-freaks’ and the desires of large IT-consultancies, the business-world does not revolve solely around IT – if anything, it revolves around people, as the term ‘enterprise’ suggests. In both TOGAF and Archimate, people are deemed solely to be Roles subordinate to the IT: might we perhaps suggest that that might be the wrong way round?
Yes, an enterprise is indeed expressed as a ‘socio-technical system’: but it involves many types of technologies other than computer-based IT – and almost none of those other technologies are currently represented, or describable, in TOGAF or in Archimate. That is the problem that concerns me here: that we have a framework that describes its own relatively-minor subset as being the centre and sum total of the space. In any true architecture, everywhere and nowhere is ‘the centre’: assigning any sole domain as ‘the centre’ creates far more problems than it solves. That is the situation right now with both TOGAF and Archimate.
Perhaps the most important problem-area in both Archimate and TOGAF is the purported ‘layering’, because that’s what both underpins and drives the IT-centrism. In TOGAF, as its stands, everything revolves around IT-infrastructure. (That’s not surprising, given where TOGAF came from. and there’s nothing wrong with that, either, as long as we don’t pretend there’s anything more to it than that.) In essence, what we have there, built-in right into the framework, is a set of viewpoints that assume the primacy of an ‘inside-out’ worldview, centred around IT-infrastructure. Applications are in context to the IT-infrastructure; ‘the business’ is in context to the applications. In that sense, everything is ‘self-centric’, where ‘self’ is the physical IT.
But now switch that round to an ‘outside-in’ view, using something like Zachman layering: contextual, conceptual, logical, physical, implementation, operation. From that view – which is the kind of view that anyone in change-projects will use – manual-processes aren’t up in the TOGAF/Archimate ‘business’ layer, they’re in the applications layer. A fork-lift truck or a warehouse-pallet and warehouse-rack aren’t in the ‘business’ layer, either: they’re technology or infrastructure. But Archimate and TOGAF force us to bundle anything ‘not-IT’ either up into the ‘business’ layer – regardless of whether it’s Zachman ‘logical’, ‘physical’, or whatever – or else ignore it entirely. And I think you’d agree that a scrambled, incomplete, misleading description of a socio-technical system is in many ways worse than having no description at all?
From what I’ve seen, none of the proposed changes from Archimate 1.0 to 2.0 will address any of those needs. Having a Location entity will definitely help us; the Dynamics extension would bring much-needed support for the implementation-stages, and help us break out of the dreaded ‘future-state’ delusions; and the Motivation extensions will definitely help us reclaim what was lost when Marc’s ‘Environment’ layer was dropped. But none of those changes resolve the IT-centrism: it leaves the ‘business = anything-not-IT’ error unchallenged, and does nothing whatsoever to fill in any of the scope-gaps or alignment-errors at the ‘Application’ and ‘Infrastructure’ layers. In short, it will give the illusion of useful change, without actually delivering much if any of the changes we most need for whole-enterprise architectures.
That’s the problem I’m concerned with here: and I fear you may not previously have understood either that the problem exists, or how serious it is in real-world whole-enterprise-scope architecture practice. Remember that IT is merely an enabler for the enterprise: as an enterprise-architect, it is essential never to make the mistake of thinking that in itself IT is the enterprise.
On Open Group and TOGAF, well, yes, there are actually a fair number of other standards-bodies in this space: itSMF and OMG, for example. OMG maintains both the BMM (Business Motivation Model) and SBVR (Semantics of Business Vocabulary and Rules) standards, and is a direct competitor (and a less IT-centric one) to Open Group in the business-architecture space.
Agreed, “Archimate is far from a finished product”, but it has been under development and in real-world use for around a decade now: it precedes TOGAF 8, for example, let alone TOGAF 9. It does concern me that under Open Group it has seemingly become more IT-centric rather than less, but that’s another story.
I’ve been actively in EA development for much the same period as Archimate, and first came across TOGAF at around the time it changed from version 7 to version 8 (i.e. before the ‘business-architecture’ layer was added in version 8.1). I’ve presented frequently at Open Group conferences over the past few years, as you’ll see from my slidedecks. But I’m not a member, in part because I don’t do much IT, but even more because I simply can’t afford it: their ‘pay for play’ membership model means that as an independent consultant I would have to pay about the same as a typical thousand-staff organisation in order to be involved in the development of both TOGAF and Archimate. And to be blunt, given that the Architecture Forum in Open Group already has some 200+ members, I think I’m probably more use sitting outside of that scramble and able to maintain a more independent view?
Again, no-one is here is ‘attacking’ Archimate per se – or TOGAF for that matter. The point is that as enterprise-architecture necessarily breaks free of its ‘traditional’ IT-centric box, those standards too need to change, and urgently, or else they will – again, of necessity – be swept aside and, of necessity, replaced. That’s the choice, right now. There’s a lot of work gone into both standards, a lot of value in there, a lot of investment in several different senses: I don’t want to see any of that thrown away. And none of it needs to be thrown away, if we can drive those necessary and inevitable changes to cover that broader scope. That’s all that I’m on about here.
Just like UML ArchiMate has no solid foundation. It is not suited for models which you can use for simulations. And not being able to run simulations is limiting its functionality to sketching. But for sketching it is better to use analog tools so there is no real value in ArchiMate…
Better languages are Perti Nets or if you like a language more similar to UML: SysML
@Peter Bakker Of course I was referring to Petri Nets (and not Peri Nets) in comment #9. Typo is my middle name 🙂
@Peter Bakker – Hi Peter – I take your point, though it kinda depends what you mean by ‘solid foundation’: there’s a lot of careful thought gone into Archimate, it wasn’t just thrown together over a weekend or two!
I’ll admit I’m too much of an anarchist to do much formal simulation: that’s an analyst’s job, not mine! 🙂 For me, the model is the sketch – or rather, the very human process of exploration and discovery of which the sketch is a kind of empty record, much as a discarded snakeskin indicates that the snake passed this way some while ago.
Much like TOGAF, the value of Archimate is that it provides a shared language and consistent checklist of items that need to be addressed. The problem is that that shared-language, whilst undoubtedly useful, is too narrow for real-world use: it’s only usable within narrow constraints that delimit a very specific subset of the real-world.
There’s a good analogy here with ‘Air International English’, the subset of English that pilots and air-traffic controllers use worldwide – an intentionally-constrained subset of the real-world language, adapted and optimised for one specific subset of real-world needs. Its time-domain is the ‘Now!’ of operations, or at most tactical, not strategic: you can use it to say that you’re going to be in the Hudson River in eighty seconds from now, but not your vague intentions about possible changes of career. You can use it to give traffic directions in the air, but it’s probably not much use for dealing with angry motorists in a minor traffic-crunch on the ground, and it doesn’t include the nouns and adjectives and structures you need to explore the merits of different types of cheese. It’s also perhaps a bit too robotic for love-poetry? 🙂
In other words, very useful in context, but misleading and too-incomplete outside of that context. A real language for the real-world has to cover the whole space, or, better, provide a solid framework in which common meaning can emerge – which is how real-world languages develop in the first place.
The problem of IT-centrism – or any other ‘-centrism’ – is that it purports that its own small subset is the sum total of the whole, or the sole reason and focus for the whole. That’s what we have right now in TOGAF and the like, when they describe themselves not as IT-architecture (which they are) but as the total scope of enterprise-architecture (which they’re not). The current implementation of Archimate falls into the same trap: it has a good overall structure, but arbitrarily constrains its nouns and verbs into a narrow subset – much like Air International English – but then purports that that subset is sufficient for the the whole (which it isn’t), yet also fails to provide the underlying generics that are needed to expand outward to allow for emergent need. That’s my concern here.
To me, the conceptual structure of Archimate is one of the best tools we have: for example, even with what we have right now, we can model layered value-networks (as long as the value can be constrained into an IT-oriented scope), whereas Business Model Canvas, for example, is optimised only to describe single nodes in point-to-point supply-chains. I’m definitely not ‘attacking’ Archimate per se: all I’m saying is that its current implementation is too constrained to be much use in real whole-enterprise architectures, and that we definitely need to be broken free of its current IT-centric box.
@Tom G
To me the conceptual stucture is to rigid, because it forces a layered structure wich I think is unrealistic. But that is not my main critic on the language. Main critic is that modeling in ArchiMate always end in discussions how you should use concepts & relations. The whole language is way too complex and unbalanced (it is developed as an Application landscape modeling language, the rest (infra & business) was an afterthougt.
The complexity of the language makes using it a bit like starting with Lego for Grownups (http://www.ted.com/talks/hillel_cooperman_legos_for_grownups.html) without the possibility to first play with the standard Duplo and Lego basic building blocks.
Furthermore ArchiMate doesn’t support a trial & error approach because you miss the simulation capability. How are you gonna proof that your model right? In other industries trial and error in a safe environment (simulation) is the most important part of & reason for modeling.
Would you want to fly in an airplane or drive a car which were modeled in a ärchiMate-like” way?
The common-language argument is not nearly strong enough to take ArchiMate for granted.
Hi Peter – thanks, yes, and points definitely taken. I’ve addressed some of those in the piece I posted just before I received this – Rethinking the layers in EA. Perhaps have a look at that, if you would, and continue the conversation in the comments-section there?
@Tom G
I will certainly read your new article, although it is hard to keep up with your pace 🙂
And hopefully I will get rid of all those typos in my comments someday …
@Tom G
Hi Tom,
I wouldn’t say that ArchiMate is IT-centric, but it certainly is “information-centric”. It was never designed for physical products or logistics. Although you might indeed use business objects in some cases, this may feel somewhat unnatural.
In the next version, we decided not to extend it in this direction, but focus on the two most requested extensions, for modelling stakeholders and requirements, and for planning. But the members of the ArchiMate Forum are well aware that there are other needs, in particular for these more business-oriented and domain-oriented issues.
The language structure itself would easily lend itself to different types of layers (or no layers at all if you like). Erik Proper and I wrote a paper about this underlying anatomy, which is not described in the standard but does underlie the construction of the language. It was published in a journal and I cannot put up a copy for download, but I can send it to you via email.
W.r.t. the connection between the BMC and ArchiMate, our conclusion (like yours) is that we need a kind of intermediate layer. I really like your Enterprise Canvas in that respect, since it seems sort of a more coherent version of the BMC. This is still very much a work in progress, but I hope it will be ready for publication within the next few months.
We are doing this in the context of our project on Agile Service Development, which is about online services and networked enterprises, so the focus will (again) be quite information-centric. Nevertheless, I hope this will provide useful input on the relationship between the “real” business of enterprises and what we in the EA community often call “the business”, i.e., everything non-IT.
As an aside: another future extension might be on domain modelling, i.e., the type of models you make before even starting to design your architecture, mapping out the concepts that are used within the domain itself; we have another interesting project on that topic, but the link with ArchiMate is not (yet) on its to-do list.
@Marc Lankhorst
For me saying that “the connection between the BMC and ArchiMate, our conclusion (like yours) is that we need a kind of intermediate layer.” is the ultimate prove that ArchiMate is such a complex and strange language that it is not capable to represent a simple model which can be drawn on a napkin.
@Marc Lankhorst
Hi Marc
Re Archimate as ‘information-centric’ rather than IT-centric, I would still have to disagree. 🙂 For example, how would I describe a card-based kanban system, as a component in an information-flow – or the reasons why I would choose a physical-based information-system rather than an IT-based one? Yes, you can sort-of do it, using a Representation for the card and an Artifact for the IT-record, but you end up with a bizarre layering-mismatch where the card is forced up into the Business layer even though it’s actually a form of Technology. That’s part of the problem that I’m on about here.
On the big-picture scale, one of the really serious problems we have in whole-scope enterprise-architectures is that we have lots and lots and lots of models and frameworks and structures for the IT part of that scope, but almost all cases they stop dead at the edge of the IT-domain, and often seem to pretend that the IT scope is the whole scope. Being unable to compare and contrast IT-specific implementations with other mixed-mode implementations makes it very difficult – if not impossible – to do end-to-end modelling for the architectures of routine business themes such as customer-journey maps, load-balancing trade-offs, limited-resource trade-offs, or business-continuity/disaster-recovery scenarios. The underlying structure of Archimate could support all of the latter – but its current implementation does not, and whilst the new extensions are nice-to-have, they don’t solve much of the real problems that I’ve outlined here.
I would very much like to see the paper that you and Erik wrote about the ‘underlying anatomy’ of Archimate (though I have a nasty suspicion that it’s what Erik told me about when we discussed this a couple of years back… in which case, yes, I definitely need a reminder! 🙁 ). I’ve been struggling with metamodelling for EA for quite a while now (for example see my 2009 post ‘More metamodel stuff‘) and really need some solid peer-review to anchor it back into real-world practice again.
Would be delighted at some point to compare notes on the ‘translation’ from business-model to detail-model – especially if we can find a way to do true round-trip modelling. I’d certainly like to see Enterprise Canvas used as a possible intermediate step, though I’m well aware that it’s still barely at the beta-test stage. I do believe that an extended Archimate – or rather, an Archimate that is not arbitrarily constrained to IT – could be the most useful end-point for the architectural detail-layer modelling, before we necessarily split into implementation-specific languages such as UML and BPMN.
On ‘domain-modelling’, please say more? 🙂 (And perhaps also include Phil Beauvoir in this conversation, as I understand he has some similar ideas for his Archi toolset?)
@Peter Bakker
Hi Peter
Re “Archimate … is not capable to represent a simple model which can be drawn on a napkin”, I would have to come to Marc’s defence here. Surely the point is that sometimes in decision-making we do need the detail that can’t be drawn on the back of a napkin?
@Tom G
I have been trying to work with ArchiMate for more than 5 years and I never managed to built a model in a “natural feeling” way. In one case, even with the help of one of the authors of “Archimate in de praktijk https://doc.telin.nl/dsweb/Get/File-62664)”/”ArchiMate Made Practical http://www.pro-mis.com/tl_files/Public%20files/archimate_made_practical.pdf” I didn’t manage to make an ArchiMate model of a real world SOA scenario at all and had to revert to Visio 🙁 to make usable diagrams for a presentation. There was and still is always a need for tweaking (using modeling tool-specific features) or bending the ArchiMate rules/concepts or by making restricting assumptions about the real-world (like you are doing in http://weblog.tomgraves.org/index.php/2011/07/26/from-biz-model-to-ea/ )
Modeling in ArchiMate is a very very time consuming process with unsatisfactory results or as Ric Phillips says: “Archimate and other UML like diagramming tools don’t rigorously specify product at the implementation end, but at the conceptual, creative end they fail to tell a compelling story that can be easily and intuitively grasped. (http://blogs.oracle.com/enterprisearchitecture/entry/ive_been_a_huge_fan)”
If you must use a UML-based modeling language please use SysML http://www.pro-mis.com/tl_files/Public%20files/archimate_made_practical.pdf and not ArchiMate. And for EA’s who are interest in modeling & simulation please take a look at the work of Wil van der Aalst http://wwwis.win.tue.nl/~wvdaalst/ (especially his work related to Petri Nets). A good primer for Petri Nets is his new book http://www.amazon.com/Modeling-Business-Processes-Net-Oriented-Cooperative/dp/0262015382
@Peter Bakker
The link to SySML should have been http://en.wikipedia.org/wiki/Systems_Modeling_Language but copy&paste in Chrome OS seams to be a bit unreliable sometimes or it is just too late for me….
@Peter Bakker
Peter,
The problem isn’t the strangeness of ArchiMate, but the vagueness/shallowness of the BMC. It hardly has any underlying concepts, and we need a bit more structure (like Tom’s Enterprise Canvas).
@Tom G
Hi Tom,
I’ll email you the paper (which is probably what Erik told you about). The domain modelling stuff happens in a project that is at the moment completely separate from ArchiMate. Nearly everything about it is still in Dutch, unfortunately, but if you can read that, see http://www.novay.nl/projecten/essence/7781. Vacation now, I’ll be offline for the next weeks.
@Marc Lankhorst
“It hardly has any underlying concepts, and we need a bit more structure” is true but there are numerous ways to achieve that goal (even without modeling languages).
I looked at Essence (thanks for the link!) and read in the paper that it is based on metapattern ideas described by Pieter Wisse at http://www.informationdynamics.nl/knitbits/htm/primer.htm
There are just a few basic concepts(the modeling building blocks) in Essence and that seems to make Essence suitable to model every context you like. Just like Petri Nets uses only a few basic modeling building blocks which makes it suitable for many different purposes. And that is also the power of the Business Model Canvas tool but that is (and that is why your remark is so true) not a modeling language but more of a (very powerful) business sketch template.
ArchiMate is a far more rigid DSL with many predefined concepts and relationships and is therefore much harder to use outside its original context (information/application landscapes in administrative environments which deal with Insurance, Social Security or Taxes).
Happy vacation 🙂
@Peter Bakker – Peter, again, agree with most of the points you make, and many thanks also for the links to SysML etc – I do indeed need to follow up on that.
@Marc Lankhorst – Marc, many thanks for the Anatomy of Archimate paper: will read, and perhaps discuss when you return from you vacation?
(Would also love to discuss Enterprise Canvas with you somewhen soon – perhaps explore ways to make it as accessible and usable as Business Model Canvas?)
@Peter Bakker – Peter, looking again at the overall structure of Archimate, it can actually be simplified down quite a long way from its current metamodel.
Much of what we see as entities and relationships in Archimate are specialisations, some of them seemingly fairly arbitrary (and unnecessarily IT-centric, as per this post). But if we strip it right back, and ignore the somewhat misleading layering, what we really have comes down to a solid, well-defined and consistent structure:
– three major categories: Passive Structure, Behaviour, and Active Structure
– within each of these categories, something that enacts the ‘is-ness’ of that category (respectively, an Object, a Function, and a container for the Function), and something that exposes that ‘is-ness’ (respectively, a Representation, a Service and an Interface)
(That’s what I get from the Language Summary page in Bizzdesign’s ‘Quick Reference’, anyway.)
Each of these items have distinct relationships with each other:
– an Object can realise another Object, and may be accessed by a Function
– a Service realises a Function, and may itself be used by another Function
– an Interface is composed of containers for functionality, and may be used by another container for functionality
– a Service may be assigned to an Interface
– a Function may be assigned to a container for functionality
(I think I’ve read the Archimate metamodel right? – please correct me if not.)
Obviously there’s a fair bit of extra detail in the metamodel, but in essence that’s all that it is: detail. And if we ensure that the underlying is and remains properly generic, but allows any appropriate specialisation, that’s about all that we’ll need. Once we strip out all the ‘clutter’ introduced by the layering (which is arbitrarily IT-centric) and all the additional IT-specific entities (ditto), it’s actually a lot simpler than it looks – and the fundamentals are solid, too.
Something to discuss some other time, anyway?
Hello Tom:
It’s curious, but I use Archimate to design some high level graphs that show how business processes are structured on orchestration mode, what IT services they use (for SOA purposes) and the link with systems. It’s called integrated enterprise architecture. It’s clear and delivers a good vision to everybody.
I find the language very straightforward and typically use the above view. There are other detailed views like application components, infrastructure, I do not use and I find it’s not need to. IT personnel my find useful translating high level requirements specified also on use cases for example.
I think it depends on the context. I never found Archimate IT centric.
@Alberto Manuel – Hi Alberto:
I’d strongly agree that it depends on the context. If what you’re doing is “show how business processes are structured on orchestration mode, what IT services they use (for SOA purposes) and the link with systems”, then no, Archimate problem wouldn’t seem too IT-centric, because that work is IT-centric already.
Now try using Archimate to do some other fairly simple IT-related tasks such as physical layout, power-distribution, or responsibility-mapping for IT service-management. You’ll soon discover that there are a whole swathe of things that you can’t describe in Archimate, yet which you do need to link in to the same model because all of them are closely-related architectural themes. But the fact that you can’t describe it in Archimate does not mean that it doesn’t exist – and if we can’t model it in some way with what purports to be ‘the notation for enterprise-architecture’, then it kinda suggests that there’s something seriously wrong either with the definition of the notation-language, the definition-in-use for ‘enterprise-architecture’, or both.
What Open Group and others have finally started to accept is that enterprise-architecture is larger than just IT. Not only that, but that it always has been larger than IT, and has always needed to be larger than IT. They are now (if often grudgingly) more willing to admit that their previous insistence that ‘enterprise-architecture’ was solely or even primarily about IT was, is and always has been a fundamental error, and often a disastrous one at that, because the artificial boundary on scope made it all but impossible to describe the full interactions even of an ‘IT’ system, let alone anything else. That’s the point that we’ve been on about here.
If you’re only dealing with a limited subset of transaction-oriented IT-architecture, current Archimate does work quite well: no question of that. Yet the moment you step outside of that very constrained scope – in other words, step out of IT-architecture and into enterprise-architecture – you’ll discover very quickly just how IT-centric Archimate really is. If your ‘world’ does revolve solely round IT, none of this will be any relevance to you, of course; but we would ask for a bit of respect for the challenges faced by those rapidly-increasing number of us who have to work with issues that extend beyond IT alone.