Abstract and concrete architectures

Introduction

The topic of “abstract” vs “concrete” architecture seems increasingly popular, especially in relation to the ArchiMate language. Recently this topic came up in consulting assignments, teaching settings, and the linkedIn group for ArchiMate. In a previous posting I briefly touched upon this topic when I wrote about the combining the specialization relation and the aggregation relation to create a plug-and-play process architecture. In this posting I will re-examine this topic. The proposed solution has been tried and tested and is now used in several organizations.

Modeling locations with Actors in ArchiMate

One of the issues that we bump into often is the question how to model a location in ArchiMate. Recently there was a long and interesting thread about this subject on the LinkedIn group for ArchiMate for example. Several options were suggested, including a suggestion that the ArchiMate language should be extended. In this blog post, I will set out my "solution" to the problem, as well as point out some issues with it.

Living 2.0

It appears that the concept of "work 2.0" or "the new way of working" (NWOW) is still quite popular as the subject is actively being discussed in many blogs, books, fora, etc. Fact of the matter is that the title / label seems completely wrong for the topic, possibly due to the fact that many companies just don't get it.

It is hard to come up with a very strict definition of what the 2.0 concept really is, or entails for companies. I'll stick to mentioning some of its aspects here to get a sense of the spectrum.

Explaining principles, and making them work

Over the last few years, many different definitions of the concept of enterprise architecture have been proposed. However, rather than focusing on definitions, the focus should be on what we can achieve by adopting architecture methods. Once we know the goals of architecture initiatives, communication/ documentation as well as the process aspects follow naturally (see e.g. this pervious blogpost).

Good intensions are not enough

In many discussions as of late, I have noticed that people tend to think of (enterprise) architecture as a communications game. For example:

• getting on the same page with respect to terms : what do we mean by application, process, product, service, etc.
• getting to grips with how we talk about change : what do we mean by current state, baseline, target architecture, building block, etc.
• getting to grips with terminology in different segments and domains in the enterprise

The list goes on and on. One of the top 3 things that people list as being a succesfactor for an architecture project is "help us talk to the other guys". Indeed, in many cases we see the intension is there: people want to talk to their peers in other departments, projects etc. If we all agree that this is a good idea, then how come it doesn't happen?

This brings me back to a previous claim: doing architecture - even with standards (like TOGAF) that people tend to think of as being IT-centric - is about the people. Helping them talk to and understand each other better will improve enterprise effectiveness.

Question to the reader: if you have any good approaches, examples, workshop forms, or other ideas to do these, let us know!

TOGAF: make it about the people

As the enterprise architecture discipline matures, more and more enterprises adopt open standards such as ArchiMate and TOGAF to deliver value to their enterprises. Indeed, most organizations realize all too well that both standards make some serious assumptions on how we see our enterprise (as a system that (a) has state, and (b) can be decomposed). As long as we - the architecture professionals - keep our eyes on the ball and know what we're doing then we should be ok, though.

In the next few weeks I will post some observations and lessons learned in the form of short articles that may be useful for others. Here's the first one: key to successful architecture projects (with our without TOGAF) is to make it about the people. Just doing "stakeholder management" as TOGAF recommends isn't good enough. Take an interest in the people that make the organization. Know, that the TOGAF framework with all its steps, checklists, guidelines etc. is only there to help you do (part of) your job better! Enterprises are about more than IT or alignment!

Business Functions & Granularity

In a previous post I already commented on the use of the business function concept in ArchiMate. A particularly tricky discussion that I frequently have during trainings and in sessions with clients involves the granularity of these services. It appears that there are two main options:

1. Business functions map to "activities" in the sense of "primary and secundary activities" in Value Chain Analysis. In this case, many processes belong to a specific business function.
2. Business functions are more finely grained and map on a competence that is recognized in an organization. As such, they are more closely linked to administrative organiztion type of research. In this case, several functions may be necessary in order to fulfill a particular process

Where the former view has the advantage of ensuring closer links between the field of enterprise architecture and strategic management, the latter appears to have the advantage of providing a mechanism for modeling the reusable building blocks of organizations. I came to appreciate this later view more after some good discussions with several clients and colleagues in the Netherlands as well as in Belgium. In this blogpost I will sketch some of my ideas and invite readers to comment and sheir their experiences in using the Business Function concept, especially when creating ArchiMate models.

The first principle that I'm proposing is to make a very tight link between business functions and business objects. That is: they have a granularity such that they mainly manipulate a single data object. Typical examples, then, are functions such as preparing an invoice, performing tax calculations, preparing a product for shipment, digitizing a document, et cetera. Note that these functions have a granularity such that they are reusable across business processes.

The logical next step is to link these functions to processes. Due to the relatively low granularity of business functions, business processes may be more coarse grained at the architecture level, which is a good thing. As is customary in ArchiMate, these businesses processes realize business services which represent the behavior of an enterprise to its environment; nothing new there.

In this scheme, business functions can be seen as "the things we need in order to be able to fulfill a business process". However, so far we've only proposed to tie them to business objects (by means of the access relationship in ArchiMate). We also need to tie other means to these functions. The main construct to be used here is that of an application service, which represents the functionality of applications that are available in the enterprise. The following example illustrates the concept so far:

By adding a layer of business functions between business processes and the means that are used to fulfill these processes, it may seem that models become needlessly complex. This is, however, not the case, as there is a big diffrence between the model (i.e., all the knowledge of all the concepts on the model) and its current representation. For many stakeholders one will generate views on the model which show only the relevant parts of it. For example, one my generate a view with processes and include the derived relationships between a process and the data objects that are manipulated in the process.

Derivation rules are relatively straight forward and the more sofisticated toolsets support these derived relations. For example:

process having acces to a business object is a process using a business function having access to that data object

The main advantage of such an approach, in my opinion, is that the business functions are easy to recognize and use in practice. They form a good starting point for modeling, and as well as provide a good starting point to gain insight in the architecture of enterprises.

On languages for enterprise architecture

Over the last few months I've been working as a consultant with a group of architects in a large organization in the social services sector in the Netherlands. The group is 'heterogeneous' in the sense that people with different backgrounds / mindsets are involved, e.g.:

• Architecture is intended as a means to set a vision "versus" architecture is intended as a process for governing change
• Architects with a business orientation "versus" architects with a technological orientation

Despite their differences, it is interesting to see that this group at the same time shows a lot of cohesion. There is definately a shared sense of purpose: help to make the organization more effective. This shared purpose leads to a a log of conversation / shared initiatives etcetera. So what can possibly go wrong?

One of the things we learned is that due to different backgrounds, education, past experience etcetera, real communication is tricky. The well-known problems with overloaded / abstract / ill-defined / ... terms made it difficult to get things done. Indeed: without communication it is impossible to co-operate effectively. To improve communication (between architects as well as between architects and 'the rest of the organization'), a choice was made to introduce a common language for enterprise architecture: ArchiMate (with BiZZdesign Architect as a supporting tool).

The ArchiMate language offers concepts and relations to discuss many aspects of enterprise architecture. Some researchers / practitioners have argued that it falls short in expressing things like organizational culture, social interactions etcetera. Even more, ArchiMate has been critisized for having so many concepts and relations between these concepts that it is hard to use. However, at the same time ArchiMate has been praised for being so rich / expressive.

Back to the client. In the organization at hand, the group recognized the potential as well as the complexity of ArchiMate as a language. We have started (and by now: completed) a project where we went over the entire language, concept by concept, and selected those that are meaningful for this group/organization. Even more, for each 'aspect' of the organization we wanted to included, we discussed at great length how to model this using the custom ArchiMate dialect.

The end result is impressive to say the least, even taking into account that we have taken quite a bit of time for the project. On the one hand, there is a body of knowledge (well documented in a formal model and supporting documents) that answers the question how we wish to document architectures in the organization. More importantly: in creating this body of knowledge, the discussions have led to improved dialogue and shared understanding.

Lesson learned: it's about the people, get the language right and get the work done!

On relation types in ArchiMate

ArchiMate is quickly becoming the industry standard for creating enterprise architecture models. Its meta-model revolves around 3 layers (business, information/application, and technology/infrastructure). The language is well suited for expressing the 'structure' part of architectures of enterprises. For example:

• actor is assigned to role
  i.e. an actor is is able to fulfill a role
• role is assigned to process
  i.e. actors fulfilling a role execute the assigned process (or possibly: are allowed to execute that process if that is the preferred interpretation)
• application component realizes application service
  application service is used by process
  application components offer their functionality to the (business) environment by means of services. The used by relation expresses that (actors involved in) processes use the functionality described by these application services

By using different types of components and different types of relations, architects should be able to craft fairly precise models on how the enterprise is structured architecturally. So far so good. But what if a relation type is missing? I.e., you want to express something for which there is no natural ArchiMate'ish expression?

Naturally, ArchiMate is setup to be a language that can easily be extended, either by adding concepts / relation types or by using profiles to add meaning to concepts / relations. However, in consulting assignments I have found that people are reluctant to do so, and tend to stick to the default set of concepts and relations.

Last week I ran into a situation where I was doing a session on the ArchiMate metamodel for a specific client. We ran into two situations where a "governs" relation type was required:

• actor governs actor
  to express the fact that, for example, one department governs another, which is intended to mean that it oversees / facilitates the other department
• process governs actor
  to express the fact that, in a context where most processes are executed automatically by a machine (computer system), one process governs the other. More specifically, it triggers, pauses, updates information, reads status information, etcetera

other uses for the same relation type are easy to come up with. The question I am struggling with is: how would you model this, using default ArchiMate?

The meaning of 'organization'

A little while ago I was faced with a writing challenge. I had to use the word 'organization' in two different meanings in a single document. As I got stuck, I asked a renowned colleague - Tom Graves - for help. On his blog, Tom posted the following response to my question. As I figured it would be interesting for a broader audience we decided to cross-post.

---

Had an interesting question come in today from one of my Dutch colleagues, Bas van Gils:

I have to write a document and I’m kinda stuck. The issue with the document is that I want to make a distinction between ‘the organization as in: “the way in which some system / department / enterprise is organized” and “the organization as in: the legal entity”. I’ve had this issue before and I can’t figure out how to deal with this properly in documents. It just feels awkward to say Organization (with capital) for meaning one and organization (without) for meaning two…

Any thoughts?

This is a real doozy of a problem that really shows up the limitations of English as a language. It’s hard enough for native English speakers to resolve, let alone those who only use English as a business-language…

I ain’t no linguistics specialist, but as I see it, the respective contexts for the two meanings are as follows:

• Meaning 1 (’the way something is organized’): a nounal expression of the verb ‘to organize’, moving from the present-participle (’organizing’) to the adjectival past-participle (’organized’) to the verb-as-condition (’organization’) [there'll be a proper linguistic term for this nounal form, but I haven't a clue what it is ]
• Meaning 2 (’the legal entity’): a label for an abstract entity that is structured (’organized’) in some defined way

To me, Meaning 1 is still more related to the verb, a temporary condition of something dynamic (”the act of organizing”), whereas Meaning 2 is definitely a noun, something static. In Meaning 1, the structure could change – the outcome of a ‘reorganization’ – and it would still be ‘organization’; whereas Meaning 2 is defined and delimited by its legal boundaries, so if those were to change, the previous ‘the organization’ would cease to exist.

[A quick check at AudioEnglish.net throws up a total of seven meanings: Bas's 'Meaning 1' is somewhere between their 1 ("a group of people who work together") and 2 ("an organized structure for arranging or classifying"), whereas Bas's 'Meaning 2' is probably closest to their 3 ("the persons or committees or departments etc who make up a body for the purpose of administering something"). The built-in thesaurus in MS Word isn't much help, either. Overall, it's all too obvious that English is a confusing mess. ]

I would probably try to juggle the phrasing so that I can avoid having to put the two meanings together in the same sentence, but I can see plenty of circumstances in which there’s no way to get round it.

If I did have to use both meanings in the same sentence, without any other option, I might well use Bas’s capitalisation kludge, though I would capitalise Meaning 2 rather than Meaning 1: “the organization of the Organization”. But as Bas says, it’s awkward and ugly: and whilst, to a native English speaker, the alternative uncapitalised “the organization of the organization” would probably be clear enough, it might not make sense to native speakers of other languages.

But as Bas again indicates, it gets messy when we try to distinguish the two meanings once we’ve bundled them together. And going back to the present-participle – “the organizing of the organisation” – is probably uglier still, although technically correct in English.

So the short answer is that I don’t see any easy way round this one. Sorry…

Anyone else have any better suggestions?