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.
December 3, 2010
November 17, 2010
October 10, 2010
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.
September 9, 2010
August 20, 2010
- 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!
August 17, 2010
June 25, 2010
- 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.
- 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:
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.
process having acces to a business object is a process using a business function having access to that data object
April 29, 2010
- 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!
March 10, 2010
- 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
- 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
February 21, 2010
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…
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?