SASSY Architecture

SASSY Architecture is a practice of combining two seemingly incompatible worldviews. The first one is based on non-contradiction and supports the vision for an ACE enterprise (Agile, Coherent, Efficient), through 3E enterprise descriptions (Expressive, Extensible, Executable), achieving “3 for the price of 1”: Enterprise Architecture, Governance, and Data Integration.

The second is based on self-reference and is a way of seeing enterprises as topologies of paradoxical decisions. Such a way of thinking helps deconstruct constraints to unleash innovation, reveal hidden dependencies in the decisions network, and avoid patterns of decisions limiting future options.

As a short overview, here are the slides from my talk at the Enterprise Architecture Summer School in Copenhagen last week.

Continue reading →

Wikipedia “Knows” more than it “Tells”

When pointing out the benefits of Linked Data, I’m usually talking about integrating data from heterogeneous sources in a way that’s independent of the local schemas and not fixed to past integration requirements. But even if we take a single data source, and a very popular one, Wikipedia, it’s easy to demonstrate what the web of data can bring that the web of documents can’t.

In fact, you can do it yourself in less than two minutes. Go to the page of Ludwig Wittgenstein. At the bottom of the infobox on the right of the page, you’ll find the sections “Influences” and “Influenced”. The first one contains the list (of links to the Wikipedia pages) of people who influenced Wittgenstein and the second, those that he influenced. Expand the sections and count the people. Depending on when you are doing this, you might get a different number, but if you are reading this text by the end of 2017, you are likely to find out that, according to Wikipedia, Wittgenstein was influenced by 18 and influenced 32 people, respectively.

Now, if you look at the same data source, Wikipedia, but viewed as Linked Data, you’ll get a different result. Try it yourself by clicking here¹.

The influencers are 19, and the influencers are 95 at the moment of writing this post, or these numbers if you click now²(most likely bigger). Continue reading →

1
If the live DBpedia is down, just delete live from the address bar where the full query will appear, and you’ll run towards the regular DBpedia endpoint
2
If the live DBpedia is down, just delete live from the address bar where the full query will appear, and you’ll run towards the regular DBpedia endpoint

Same as Magic

When I started my journey in the world of Semantic Web Technologies and Linked Data, I couldn’t quite get what was all that fuss about the property owl:sameAs. Later I was able to better understand the idea and appreciate it when actively using Linked Data. But it wasn’t until I personally created graphs from heterogeneous data stores and then applied different strategies for merging them, when I realised the “magical” power of owl:sameAs.

The idea behind “same as” is simple. It works to say that although the two identifiers linked with it are distinct, what they represent is not.

Let’s say you what to bring together different things recorded for and by the same person Sam E. There is information in a personnel database, his profile and activities in Yammer, LinkedIn, Twitter, Facebook. Sam E. is also somebody doing research, so he has publications in different online libraries. He also makes highlights in Kindle and check-ins in Four-square.

Let’s imagine that at least one of the email addresses recorded as Sam E’s personal email is used in all these data sets. Sam E. is also somehow uniquely identified in these systems, and it doesn’t matter if the identifiers use his email or not. When creating RDF graphs from each of the sources, URI for Sam E. should be generated in each graph if such doesn’t exist already. The only other thing needed is to declare that Sam E’s personal email is the object of foaf:mbox, where the subject is the respective URI for Sam E from in each of the data sets.

The interesting thing about foaf:mbox is that it is “inverse functional”. When a property is asserted as owl:inverseFunctionalProperty, then the object uniquely identifies the subject in that statement. To get what that means, let’s first see the meaning of a functional property in OWL. If Sam E. “has birth mother” Jane, and Sam E. “has birth mother” Marry, and “has birth mother” is declared as functional property, a DL reasoner will infer that Jane and Marry are the same person. The “inverse functional” works the same way in the opposite direction. So if Sam.E.Yammer has foaf:mbox “sam@example.com”, and Sam.E.Twitter has foaf:mbox “sam@example.com”, then Sam.E.Yammer refers to the same person as Sam.E.Twitter. That is because a new triple Sam.E.Yammer–owl:sameAs–Sam.E.Twitter is inferred as a consequence of foaf:mbox being owl:inverseFunctionalProperty. But that single change brings a massive effect: all facts from Yammer about Sam E are inferred for Sam E from Twitter and vice versa. And the same applies for LinkedIn, Facebook, online libraries, Four-square and so on.

Now, imagine you don’t do that for Sam E, but for all your Twitter network. Then you’ll get a graph that will be able to answer questions such as “From those that tweeted about topic X within my network, give me the names and emails of all people that work within 300 km from here”, or “Am I in a same discussion group with somebody that liked book Y?”. But wait, you don’t need to imagine it, you can easily do it. Here is for example one way to turn Twitter data into an RDF graph.

Of course, apart for persons, similar approaches can be applied for any other thing represented on the web: organisations, locations, artefacts, chemical elements, species and so on.

To better understand what’s going on, it’s worth reminding that there is no unique name assumption in OWL. The fact that two identifiers X and Y are different, does not mean that they represent different things. If we know or if it can be deduced that they represent different things, this can be asserted or respectively inferred as a new triple X–owl:differentFrom–Y. In a similar way a triple saying just the opposite X–owl:sameAs–Y can be asserted or inferred. Basically, as long as sameness is concerned, we can have three states: same, different, neither same nor different. Unfortunately, a fourth state, both same and different, is not allowed, and why would that be of value will be discussed in another post. Now, let’s get back to the merging of graphs.

Bringing the RDF graphs about Sam E, created from the different systems, would link them in one graph just by using foaf:mbox. Most triple stores like Virtuoso, would do such kind of basic inferencing at run time. If you want to merge them in an ontology editor, you have to use a reasoner such as Pallet if you are using Protégé, or run inferencing with SPIN, if you are using TopBraid Composer. Linking knowledge representation from different systems in a way independent from their underlying schemas, can bring a lot of value, from utilising chains of relations to learning things not known before linking.

The power of “same as” has been used a lot for data integration both in controlled environments and in the wild. But let’s not forget that in the latter, the web, “Anyone can say anything about anything”. This was in fact one of the leading design principles for RDF and OWL. And then even with the best intentions in mind, people can create a lot of almost “same as” relations that would be mixed with the reliable “same as” relations. And they did and they do.

The problems with “same as” have received a lot of attention. In one of the most cited papers on the subject, Harry Halpin et al. outline four categories of problems for owl:sameAs: “Same Thing As But Different Context”; “Same Thing As But Referentially Opaque”, “Represents”, and “Very Similar To”. Others worn about problems with provenance. Still, almost all agree that the benefits for the owl:sameAs for Linked Data by far outnumber the risks, and the latter can be mitigated by various means.

Whatever the risks with owl:sameAs in the web, they are insignificant, or non-existent in corporate environments. And yet, most of the data stays in silos and it gets integrated only partially and based on some concrete requirements. These requirements represent local historical needs and bring expensive solutions to local historical problems. Those solutions typically range from point-to-point interfaces with some ETL, to realisation of REST services. They can get quite impressive with the means for access and synchronisation, and yet they are all dependant on the local schemas in each application silo and helpless for enterprise-wide usage or any unforeseen need. What those solutions bring is more complicated application landscape, additional IT investments brought by any change of requirements and usually a lot of spendings for MDM software, data warehouses and suchlike. All that can be avoided if the data from heterogeneous corporate and open data sources is brought together into an enterprise knowledge graph, with distributed linked ontologies and vocabularies to give sense to it, and elegant querying technologies, that can bring answers, instead of just search results. The Semantic Web stack is full of capabilities such as owl:sameAs, that make this easy, and beautiful. Give it a try.

The Infatuation with "Building Blocks"

Why the majority of Enterprise Architects are in love with the concept of “building block.” Perhaps because blocks don’t answer back and spoil the design, Aiden Ward suggested.

In TOGAF 9.1 “building block” is used 349 times, not counting the separate use of ABB and SBB acronyms. There is a whole chapter devoted to building blocks. In there, we find the following:

A building block is a package of functionality defined to meet the business needs across an organization.

A building block has a type that corresponds to the TOGAF content metamodel (such as actor, business service, application, or data entity)

A building block has a defined boundary and is generally recognizable as ‘‘a thing’’ by domain experts.

Now, if a “building block” is a “package of functionality,” taking it together with the second statement, then “actor” and “data entity” are – according to TOGAF – types of “package of functionality.” That doesn’t bother me so much, as logic and consistency have never been among the strong sides of TOGAF. I’m more concerned with the last statement. There are indeed some entities from the model that are recognized by domain exerts as “things” with defined boundaries, but I’m yet to hear a domain expert using “building blocks” to discuss their business. Even if there are some that do, having surrendered to the charms of eloquent Enterprise Architects, I doubt they use that language among themselves. And they don’t need to.

Enterprise Architecture is not unique in using technology metaphors to understand its organization. After some circulation of the brain as a metaphor for the computer in computer science, then cognitive science returned the favor by using the computer as a metaphor for the brain. Not only that, it guided the thinking of most cognitive scientists to “prove” that the brain is doing information processing. That school of thought, the so-called computationalists, still has a lot of followers today. The same school regards the mind as “running” on the body just like software is running on hardware. That approach has been doing much more harm to an array of disciplines than the usage of building blocks in Enterprise Architecture. But qualitatively, it is a similar phenomenon.

It’s now time to choose some structure for building the point about my puzzlement (and then hopefully solving it), and I select the following titles for my text blocks: name, history, and purpose.

Name

The primary source of irritation is the name itself. But it is also a minor one, so we can quickly deal with it.

Where is the name coming from?

EA is often perceived by non-EA people as something coming from IT, which is not even proper IT. The IT parlance, in general, has borrowed a lot of terms from other engineering practices. Software development has shown a preference for construction engineering over – what would have seemed a more natural choice – electronic engineering. And that’s why we are “building” software. Keeping in mind how iterative that is, if that “building” is brought back and applied to actual buildings, there won’t be many happy investors or inhabitants.

Anyway, “to build”applications is well established and doing well in software development. But what is the utility of “building block” in Enterprise Architecture? Indeed, representing some abstractions as boxes and placing them one over another resembles playing with Lego. The metaphor brings a more than welcome simplicity to the architecture discussions. But, apart from smoothing communication between Enterprise Architects, is it useful for anything else? And how does the name reflect the actual use of the concept?

My quick answer is that nothing can be built using architectural building blocks. Something can be drawn and then reconfigured in another drawing. Isn’t it then more appropriate to talk about “description” blocks or “design” blocks?

Some Enterprise Architects are well aware of that. In fact, it seems that the choice of “building block” over “component” is exactly to remind the users that the former is not the latter but just an abstract representation of it. This has been debated for about a decade, and various solutions have been proposed, including “reusable” blocks, which would make the purpose explicit, at least.

But this awareness is neither widespread nor persistent enough to prevent the stabilization of some thinking habits. They lead to decisions that look good only within the protected virtual reality of architecture descriptions.

History

There are two lines of history we can follow. One is the evolution of “building block” in the Enterprise Architecture discipline; the other is how a building block comes about in a concrete EA practice. If that were about species, a biologist would call the first line phylogenesis and the second one ontogenesis.

Following the first one would probably reveal interesting things but would require an effort that the concept does not justify. That’s why I’ll limit tracing that history to the hypothesis of the origin I discussed in the Name section.

A building block in a concrete enterprise architecture practice is a specialization of a generic element. That generic element is based on a history and knowledge of different concerns at the moment of the meta-design, and the important patterns that need to be represented. These are, if we take Archimate as a popular example, things like Role, Event, Process, Service, Interface, and Device. Their application, however, is limited by three restrictions:

first, when an entity is represented, it has to be as one of these types;
second, the criteria for making the choice come from interpreting definitions of these concepts and not from what the represented object from the real world has or does (there are generalized relations, but they are not used for that);
third, something cannot be represented as more than one concept.

So, a building block, being a specialization of a concept, asserted in this way, inherits both this set of restrictions and everything else that’s coming from the object-oriented paradigm, which the use of “specialize” and “inherits” implied already.

Purpose

The use of building blocks in Enterprise Architecture is either directly supporting or historically linked with reusability.

A building block represents a (potentially re-usable) component of business, IT, or
architectural capability that can be combined with other building blocks to deliver
architectures and solutions. (TOGAF 9.1, p.11)

In order to support reusability, building blocks should have the right level of granularity. Basically, they need to balance flexibility and efficiency. In order to be reused, which would mean recombined, they shouldn’t be too coarse-grained; otherwise, there won’t be enough flexibility. On the other hand, if they are too fine-grained, it won’t be efficient to maintain reference architectures.

Now, this seems key for understanding the popularity of “building blocks.” Enterprise Architects have to justify their reason-to-be. As both reusability and flexibility make a good business case, the stabilization of that concept could be just due to survival pressures. And then Enterprise Architecture, in order to exist as such, should not only be allowed and fed but should have ways to assert itself as a social system. The “building blocks” provide one of the conventions that make the network of communications within the EA practice sustain its identity.

Fine then, problem solved: Enterprise Architecture, being predominantly practiced the way it is now, needs concepts such as “building blocks” in order to survive as an economic entity and as a social system.

And yet, Enterprise Architecture can be practiced and can bring more benefits without building blocks, layers, tiers, and suchlike. It can be done by not reducing what is learned in the process to what was decided at the moment of knowing, much less when the meta-model was fixed. The objects that need to be described and designed can get their type from how their descriptions satisfy the conditions for classification. Last but not least, it could be done entirely in the language that domain experts use, and “building block” is not used by them, at least not in the service industry. When it is used by actual builders, I doubt they mean “package of functionality.”

The Pathologies of Silo-fighting

The division of labour has been the main principle for structuring organisations in the last two centuries. That is still the dominant approach for allocating resources, information and power in companies and public institutions. The new dynamics in a connected world have revealed a rich spectrum of problems related to these structures ranging from ineffective coordination to turf wars. This gave birth to the stigmatising label ‘silos’ and a whole industry of silo-fighters armed with silo-bridging or silo-breaking services, methods and technologies.

Here I will point out the two most prominent organisational pathologies brought by such silo-fighters. I’ll split the silo-fighters’ strategies into silo-bridging and silo-breaking – an oversimplification – to make the illustration of the two pathologies more clear.

‘Bridging the silos’ is not a strategy based much on appreciating their role and thus opting for bridging over breaking. It’s mainly due to silo-fighters’ insufficient resources and power. If they manage to sell successfully the story of the bad silos, coming with a rich repertoire of metaphors such as walls, chasms, stove-pipes, islands and such like, then they get permission to build – as such a narrative would logically suggest – bridges between the silos.

Now, the problem with bridges is that they are either brittle and quickly break, or they are strong enough to defend their reason to be. They break easily when they fail to channel resources for a longer time than the patience over their initial failures would allow. However, identity formation switches on viability mode. The bridges start to grow out of a network of decisions supporting their mission, now turned into an ongoing function. If the reason the bridges exist are silos, and the bridges want to keep on bridging, then the silos have to be kept healthy and strong as they are what the bridges hang on to.

The bridges reinforce and perpetuate themselves up to a point, in which they are recognised as silos, and the problem is solved very often by building new bridges between them. This is how a cancerous fractal of bridges starts to grow. As attractive as this hyperbole is, I have witnessed repeatedly only two levels of recursion, but isn’t that bad enough?

In contrast, the silo-breaking strategies want nothing less than the destruction of silos. There, the silos are seen only in their role of a problem. Nobody asks what kind of problems this problem was а solution to. Instead, these silo-fighters start waging exhausting wars. The wars can end up in several ways. A common one is resource depletion. Another is with the silos withstanding, or with the silo-fighter being chased away or transformed. And then of course it could be the case of victory for the silo-fighters. And this is when the disaster strikes. Having the silos down, the silos fighters are faced with all the problems being continuously solved by the silos during their lifespan. Usually, they have no preparation to deal with those problems, neither they have the time to come up with and build alternative structures.

When discussing these two pathologies, it is very attractive to search for their root cause and then, when found, fix it. But that would be exactly the fuel these two types of silo-fighters run on. It takes a deeper understanding of the circularity of and in organisations, to avoid this trap. By ‘understanding’, I mean the continuous process, not the stage, after which the new state of ‘understood’ is achieved. And it takes, among other things, the ability to be much more in, and conscious of it, and at the same time much more out, but only as a better point for observation, not as an attempt for excluding the observer.

Language and meta-language for Enterprise Architecture

That was the topic of a talk I gave in October 2014 at an Enterprise Architecture event in London.

Most of the slides are available as PDF slidedeck on Slideshare.

They probably don’t tell the story by themselves, and I’m not going to help them here unless this post provokes a discussion. What I’ll do instead is clarify the title. “Language” refers to the means of describing organisations. They could be different. Given the current state of maturity, I have found those based on description logic to be very useful. What I meant by the “current state of maturity” is that a method in its theoretical development, application, the technologies supporting it and the experience with their application justifies investments in utilising them and helping in their further development. Although I find such a language clearly superior to the alternatives in use, that doesn’t mean there are no issues and that no approaches are showing convincing solutions to those issues. However, the practice with the latter or with the available tools doesn’t give me enough reason to stand behind them. The situation with the “meta-language” is similar, but let’s first clarify why I call it that.

Metalanguage is commonly defined as language about language. If that was the meaning I intended, these notes here could have been referred to as a mixture of another meta- and a meta-meta-language. That’s not the case. But to clarify the intended meaning of “meta,” I need to first clarify “language.”

I have found that there is a need to describe properly the “objects” that people in organisations are concerned with and how they relate to each other. It could be some way of representing physical things such as buildings, documents and servers or abstract concepts such as services, processes and capabilities. And although it relates also to abstract things, I sometimes call it “language for the substance”.

Organisations are autonomous and adaptive systems, continuously maintained by their interaction with their niche, the latter being brought forth from the background, by that very interaction. While a language such as the one proposed can be useful to understand the components of an organisation, it doesn’t help much in understanding the dynamics and viability. The language for the substance cannot be used to talk about the form. That’s why there is a need, maybe temporarily until we find a better solution and probably a single language, to have another language and that other language I called meta-language in the presentation.

As this is a language for the form, I keep looking for ways to utilise some proposals. One nominee is George Spencer-Brown’s Laws of Form (this post includes a brief introduction). Papers like this one of Dirk Baecker give me hope that it is possible. Until then, for the purposes of Enterprise Architecture, I find the Viable System Model, with the whole body of knowledge and practice associated with it, as the most pragmatic meta-language.

Related posts

SASSY Architecture

Reasoning with Taskless BPMN

Was it Lisbon that attracted me so much or the word Cybernetics in the sub-title or the promise of Alberto Manuel that it would be a different BPM conference? May be all three and more. As it happened, the conference was very well organised and indeed different. The charm of Lisbon was amplified by the nice weather, much appreciated after the long winter. As to Cybernetics, it remained mainly in the sub-title but that’s good enough if it would make more people go beyond the Wikipedia articles and other easily digestible summaries.

My presentation was about using task-free BPMN which I believe, and the results so far confirm, can have serious benefits for modelling of both pre-defined processes and those with some level of uncertainty. In addition, there is an elegant data-centric way to execute such processes using reasoners. Enterprise Architecture (EA) descriptions can be improved if done with explicit semantics. Currently, EA descriptions are isolated from the operational data and neither the former is linked with what happens, nor the latter get timely updates from the strategy. More on this in another post. Here’s the slidedeck¹:

1
You can watch on YouTube the slides with animations (no voice-over) and a 7 min compilation of the talk.

Frameworks and rigour

This is in response to the recent article of Richard Veryard “Arguing with Mendeleev”. There he comments on Zachman’s comparison of his framework with the periodic table of Mendeleev. And indeed there are cells in both tables with labelled columns (called “groups” in Mendeleev’s) and rows (“periods” respectively). Another similarity is that both deal with elements and not compounds. The same way the study of properties of oxygen and hydrogen will tell you nothing about the properties of water, the study of any two artefacts from Zachman framework will tell you nothing of how the real things they stand for work together. In fact you may not even get much about the separate properties of what the artefacts represent. Anyway, if there are any similarities, this is where they end.

I’ll not spend much time on differences. They are too many. But let me just mention two. The periodic table is a classification based on the properties of the elements. The order is determined by atom numbers and electron configuration. Both groups and periods have commonalities which make them an appropriate classification scheme. Once the rules are established, the place of each element can be confirmed by independent experiments and observations. That’s not the case with Zachman’s framework.

Richard comments on the statement that Zachman’s scheme is not negotiable:

What makes chemistry a science is precisely the fact that the periodic table is open to this kind of revision in the light of experimental discovery and improved theory. If the same isn’t true for the Zachman Framework, then it can hardly claim to be a proper science.

I haven’t heard the claim that Zachman’s framework is a “proper science” before. In my opinion, Zachman’s main contribution is not his framework as such but the fact that it created a new discipline and new profession. The scheme itself is arbitrary. The columns, as we know, are based on six of the interrogatives: what, how, where, who, when, and why. Whether is missing, also how much. In the old English there is also whither, which is similar to where but has an important specifics – it is related to direction (whereto). But I’m not questioning the number of columns. I have doubts about their usefulness in general.

Let’s just take three of the of the interrogatives: what, how and why and test some questions:
1. What do you do now? Answer: B
2. Why do you do B? Answer: because of A
3. How do you do B? Answer: by means of C

And now with a simple example:

B = buy food

A = I’m hungry

C = going to the supermarket

Now let’s focus on the answers and ask questions to learn more. First on C:
I’m going to the supermarket.
Why? Answer: to buy food
Why you need to buy food? Answer: because I’m hungry

Now let’s focus on A:
I’m hungry. Well, this is a problem. So we can ask:
How can I solve A? Answer: by doing B
How can I do B? Answer: by doing C

So if the relativity of the focus is ignored then what is equal to why is equal to how. (Speaking of focus, or perspective, this is where the rows in the framework come to play. This is a nice game itself which we’ll play another time).

In this example the answer of what is related to activities and not to their object (food) which by itself questions how appropriate is to label the data column “what”.

But of course rigour is not imperative. And neither is logic. After all it shifted its function from a tool to win arguments into a tool to seek truth. And then logic is quite materialistic, while EA seems a spiritual practice. Which reminds me also of the mind over matter one-liner:

If you don’t mind, it doesn’t matter.

drEAmtime

In the Australian Aboriginal culture, Dreamtime “is a complex network of knowledge, faith, and practices”. This definition can be reused for another human activity, Enterprise Architecture(EA), and Dreamtime fairly describes its current state¹.

The drEAm of the common language

It is believed for a long time now that there is a widespread misalignment between ‘Business’ and ‘IT’. The IT in this context is used to refer to employees that carry out activities closely related to development, procurement and maintenance of information systems, and ‘Business’ – to those who don’t.

The division of labour, which is the predominant way of structuring organisations, naturally invites different specialists with different backgrounds. Naturally, they use different terms or the same but with different meanings. Even if this is the same between accounting and production, the miscommunication between IT and the rest gets more attention. Maybe it is due to the increasing dependency on IT combined with stories of spectacular failure. Or it might be because IT is an area with a high rate of innovation, and the sense of leading doesn’t go well with the need to follow orders from those belonging to somewhat lagging ones. In any case, there is general agreement about the problem of miscommunication and the associated high cost.

Here comes Enterprise Architecture to the rescue. By doing what? Introducing a third language.

What’s even worse, this language is ostensibly similar to both ‘Business’ and ‘IT’. Just check some EA terms to see how people from ‘Business’ and ‘IT interpret them. Take, for example, the most common ones like service, capability, function, model, viewpoint and artefact. The resulting situation looks something like this:

It looks absurd, but let’s imagine for a moment that it’s not. At best, we would see the following vicious circle. The strong IT smell of the EA language decreases the chance of the Business believing that they would benefit from learning it, hence the low motivation and buy-in. Even though the cognitive load for IT is much lower, seeing the willingness of the Business to ‘improve’ its literacy, IT people find better things to be busy with. And another funny point. When there is some buy-in by the Business, EA is put under IT, not between business and IT. Then EA people complain they can’t do much from there. But maybe they are put there just because they can’t do much.

Closely related to the dream of a common language is

The drEAm of bridging the silos

That it is a dream should be already obvious from the previous, about the common language. But here is another aspect. The EA people build bridges between silos that turn into new silos. At a certain point, they find themselves in a position where neither business nor IT regards them as a bridge anymore. Business people trust EA people even less than IT because they see them as cross-dressed IT. IT people lose trust in EA as well because they are not sure they understand the Business and if they still remember what IT was. Further, IT managers need support, which EA does not have the authority to ensure.

And there is an additional effect. EA is often in the position to attract some serious budgets for reasons we’ll see in another dream, and this way, the new island becomes a safe territory for people who have either failed or lost interest in pure IT. This further decreases the credibility of enterprise architecture and in some organisations, they get the image of people who are not good enough for IT and prefer to hide under EA labels where things are vague enough and difficult to measure. The lost credibility either undermines the work of the good EA practitioners or pushes them out of the organisation or both.

But what part of the work of EA is quantifiable? One tangible result of successful EA seems to be the rationalisation of the application landscape. And as this brings efficiency, it is easier to measure. This I call

The drEAm of IT cost reduction

Big organisations in all sectors, especially in the service industries, tend to amass a huge number of applications until there are far too many to manage. A good number of them are not used at all. Others are underutilised. Most of the critical applications have high maintenance costs, high replacement costs, or both. Inevitably, there are many which automate different parts of the same process, but they don’t talk to each other. And this justifies new spending on building interfaces or buying application integration packages first and then replacing them with BPMS and then probably with something better than BPMS. As a result, there is more spending and more applications to manage.

Application integration problems are accompanied by problems of duplication of IT investments. Existing functionalities are duplicated in one or more applications to some extent or completely.

Yet another common situation is patchwork applications. Those are applications that have certain utility but don’t quite well meet the needs, or just the needs change. In any case it is found better to add the missing functionality instead of replacing the whole application. And then, again and again, layers of patches of additions and fixes until we have a real monster and the roles of the master and servant are swapped.

One day all these silo applications, functional redundancies, patchwork systems, and suchlike create a serious mess and shocking numbers in the financial statements that are serious enough to convince the top management that something has to be done rather soon.

But just when the situation seems really critical, the door opens with a kick and EA cowboys enter. They pull out frameworks and architecture tools from their holsters and in slow motion (a very slow motion), they shoot inefficiency after inefficiency until all of them lie dead on the floor. Then they walk out and go to shoot inefficiencies in some other town and when new inefficiencies appear in this town they come back again to kill them out.

Here is what actually happens. Some attempts to achieve IT rationalisation fail spectacularly. I’m not going to list out the reasons for that. It is maybe sad that such failures discredit EA as a management discipline as a whole. But sometimes, enterprise architects are really able to find ways to discover what’s not needed and how to remove it, what is underutilised, and how to achieve better ROI for it. After all, most of them are smart people using good tools. And indeed, they shoot inefficiencies, and some get all the glory and the money to shoot more. However, as they rarely get to the cause of the inefficiencies or are in a position to influence the bigger system that produces these inefficiencies, the overall result is an increase in overall IT spending. Why? The success of such EA efforts justifies a bigger EA budget, which is almost without exception a part of the IT budget.

The drEAm of dealing with complexity

This dream has specifics of its own, but it can also be used to explain the whole dilemma.

If you are an Enterprise Architect, a popular way to deal with complexity is to arm yourself with a framework. It is believed that you can do two things with a good framework. First, reduce the complexity of the enterprise to just a few things that share the same properties, according to some classification theory and where things doesn’t fit, add more layers of abstraction. And second, reduce the things you can possibly do to just a few but well-defined and in a specific order, with well-prescribed inputs and outputs. That was common for so many organisations that did well that it became a best practice, and the chances are, if you follow this way, it will do you well as well. Now, because of the shared understanding of the beneficial role of the abstract layers, and the boundaryless imagination unconstrained by reality, there is a serious number of frameworks and, on top of them, other works on how to adapt and adopt them.

Then of course modelling itself is believed to help in dealing with complexity. But what kind of modelling? A very complicated architecture diagram does not show complexity. It just shows a lot of effort spent in denial of it.

The part related to complexity certainly deserves a separate post and maybe more than one. For now, let me just finish with the following: dealing with complexity is not reduced to finding ways to reduce it. It requires a different understanding of what happens when interactions are not linear when there is context, history, emergence, adaptation, politics and power. Complexity is a property of the enterprise, not a problem to be solved.

In summary, more often than not, when contemporary mainstream EA is trying to introduce a common language, it creates confusion and additional work to deal with it. When trying to bridge the silos, it creates new silos instead. When trying to reduce the IT spending, it, in fact, makes no change or increases them. When trying to deal with complexity, it’s just pathetic.

1
With this, I’d like to depart from further analogies as I respect the culture of Aboriginal people in general in the part related to Dreamtime. I’ll refer to drEAmtime in this article solely as to what I currently see as the EA’s state of play.

Modernising Job Titles

HR Manager: What do you do?

DB Designer: I work with databases.

HR Manager: More specifically?

DB Designer: I design them.

HR Manager: Good, so you are an Architect!

DB Designer: Well, yes, you can put it that way, I guess.

HR Manager: Who uses the databases you design?

DB Designer: Many departments, in fact a big part of the enterprise.

HR Manager: Great, so you are an Enterprise Architect. That’s your new title, congratulations!

DB Designer: …!?

(related post: Where to start?)

The efforts spent on definitions

Definitions are attention-seekers. And good ones. They get much more attention than they deserve.

I’ve just read a post by Nick Malik called Many (flawed) Definitions of Business Architecture. There, he does a very good job of analysing the existing definitions of Business Architecture. He comes to the conclusion that all of them need to be improved, including his own one.

Tom Graves recently wrote about the Meaning of process. In my comment, I asked why we need to agree on a process definition. For similar reasons, I doubt that we need to spend too much effort on arriving at a better definition of Business Architecture.

Would a better definition, being some-body’s statement or many-body’s convention, make a definition-compliant Business Architecture better? Would making Business Architecture better make the business better? The business may get better without a good Business Architecture, and having a good one would not necessarily make it better. Quite similar reasoning applies to definitions. You can have a good Business Architecture with a wrong definition and vice versa.

Nick Malik listed and categorised 20 definitions of Business Architecture. The fact that there are so many speaks about the amount of effort spent on them, including on discussing them. Not that I’m not tempted as well. Especially by some of them. Let’s quickly check, for example, the definition of TOGAF, starting not with the explicit statement, but the implicit meaning taken from the TOGAF content. (Here I go, I could not resist) If something belongs to the Business Architecture domain, it doesn’t belong to Application Architecture unless I’m misreading something. For example, applications are not part of the Business Architecture. Well, if we strip down the Architecture dress, applications do not belong to the business. Although the business paid for them. Nice. Business is practising Aparigraha. I’m all for.

If the business is split into social and technical parts, then applications would rather be in the technical than in the social. That I can understand. But when we distinguish business and application domain… Or maybe when ‘business’ is used as an adjective for architecture, things are different? Anyway, it seems that this type of abstraction works in some contexts. Or at least I hope so, otherwise why so many smart people are following TOGAF? Still, some deductions from the Architecture of TOGAF make it not a very reliable tool for the Architecture of the Enterprise.

If we take the explicit definition itself, things get even worse: “The Business Architecture defines the business strategy, governance, organization, and key business processes.” Business architecture does not define strategy; people define strategy. It might be that there are models used to support the strategy, and these models are classified as belonging to Business Architecture. But that doesn’t help the statement make more sense.

Now again, back to content, there is very little mentioned about strategy in the TOGAF Architecture Development Method, although it deals with Business Architecture to support the claim that it is an Enterprise- and not an IT-architecture framework. Then, in the Architecture Content Framework, things such as driver, goal, objective and measure appear (recently!) in something called ‘Motivation Extension’. Isn’t it odd to have goals and drivers in an extension? Shouldn’t we rather place them in a… more central place?

Maybe it’s better to determine things by their relation with other things, such as relating talk with a walk (the above example refers), a model with reality, and sense with common-sense…

On the other hand, definitions are important. They really are, though a bit less in the areas such as Enterprise Architecture. It’s just that spending too much effort on them often has high opportunity costs.

Beliefs and Capabilities

Beliefs are powerful. Sometimes, all we need to achieve something is to hold on to our beliefs. However, there are times when we can’t get where we want to be unless our beliefs are shaken and eventually changed.

Beliefs can influence our capabilities. And the evidence of our capabilities can change our beliefs.

Let’s explore this a bit.

Beliefs

Our conscious actions are based on conscious decisions and unconscious determinants, and all of them — on our beliefs. Our actions change the environment and ourselves, and then we sense and interpret the changes, which in turn influence our beliefs and actions. One way to see these interdependencies is by using Chris Argyris’s ladder of inference. You can easily find a lot of resources based on the original model on the web. Here I’ll build on an interpretation by Gene Bellinger where it’s represented not as a ladder but as a reinforcing inference cycle.

From the observable data and experience we select some and affix meaning to them. This feeds our assumptions. Then, we come to conclusions that, in turn, influence our beliefs. Our beliefs determine our actions. Our actions bring more data and experience from which we select some, affix meaning, and the cycle repeats. We tend to believe that we affix meaning to the observable data, oblivious of the selection we always make. In a similar way, we believe that we draw conclusions by clear reasoning, while we actually always apply some assumptions.

I’ve made a few modifications to this cycle. The first one is making some of the choices explicit. We make choices in several places in the cycle, notably before Actions but also after Observable data where we choose what to pay attention to. We also make choices when we try to make sense of them. For now, I added only one more variable: ‘Decisions’. It comes before Actions and after Beliefs. Our Actions are based on Decisions that are influenced by our Beliefs.

Now, the cycle looks like this:

The second modification is the addition of another direct influence, the one between Beliefs and the sense we make out of the selected experience. Our beliefs reduce our perception range (the balancing loop B2), as well as the way we select what meaning to affix to what we have chosen to pay attention to (the balancing loop B3). Thus, Beliefs affect three types of choices we make: on actions, on the selection and on the interpretation of data and experience. Now we have three loops, and depending on which one of them is stronger, the system can work in different ways. It can work as a learning cycle or as an obsession. It can also work as something that I call a ‘sustainable system of fallacies’.

Yes, Beliefs influence directly action, selection, and interpretation but they go even further than that.

…and Capabilities

As with beliefs above, it’s easier to use something that has proved working than starting from scratch. My choice of model here is the logical levels of Robert Dilts. Again, I made a small modification, but only to the style:

Apart from refocusing, this modification makes it look like a tornado. And I like it like that.

This model is useful in a range of domains, from communication and therapy to management and leadership. Dilts gives a good communications example with the different choices a teacher has for commenting on a student’s poor results on an exam. The suspected cause can be a noisy room, thus giving feedback at the environmental level. Alternatively, the teacher can point out that particular performance instance, thus addressing the student at the level of behaviour, or comment on student’s current skills on the examined subject which are at present less developed than on other subjects. That is an example of communication at the level of capabilities. Yet another option is to discuss the importance of this subject and by doing so to touch the value system (level of beliefs). And last, of course, is the worst choice, calling the student stupid, hitting the student at the level of identity.

According to Dilts, “a belief is a generalization about a relationship between experiences”. He points out more specifically those about causal relationships, meaning and limits. The latter seems very pertinent to the way beliefs influence capabilities. But there are other ways as well.

An insight on those comes when we merge the two models. All variables in the cycle of inference, with the exception of Observable data and experience, are influenced by a certain type of capability. The most obvious one is our capability to carry out the chosen Actions. It may be an existing one which we have access to and can use, or one that exists but we are not conscious of and don’t have access to. The third case is when the chosen actions need capabilities that we have to build or buy.

In a similar way we need capabilities for data selection and sense-making. Next comes our capability to challenge assumptions. As all reinforcing loops, this one can be vicious or virtuous. Sometimes the difference between one or the other may depend just on our capability to challenge assumptions.

While looking at this model, we shouldn’t forget that one’s inference cycle is linked with the inference cycles of others. One such influence can be easily seen when we look at Decisions. When a politician makes certain promises during elections, that would create experience for others and expectation, for example, that the promise will be kept. Many cycles later, that politician may have other beliefs, based on new experience but decide to make actions based on old promised to maintain the perceived trust although she may believe that these actions would not have positive outcome to those whose expectations should be met. Or the opposite. She may follow her new beliefs, which would fulfil the expectation of those who did not believe in initial promises and disappoint those that did, thus having less support to carry out the chosen actions although they might be those that would bring better outcome for both groups. The choice would depend on values. Beliefs and values are closely connected.

There are more findings to share about all the variables in the cycle and those representing some types of capabilities. But let’s first apply it to itself and try to put it in a learning loop:

I believe that this model, which is based on some filtering and sense-making choices, now that is published, will add to the available data and experience, which will provoke hopefully some feedback to add more data, on which we’ll make new selections and will probably change our assumptions, conclusions and eventually beliefs. Then, based on what we’ve learned, we might come up with a better model.

Where to start?

The Developer: “Let’s start coding. We don’t have time for solution design.”

The Designer: “No, we should design first. It’s not a waste of time. It will reduce rework.”

The Analyst: “Guys, please! How to start designing, if we don’t know what the problem to be solved is?”

The Tool-lover: “But how to diagnose the problem without a tool? Let’s choose the tool first.”

The Architect: “Yes, but to choose a tool, we first need to make sense of the context and only when we know where we are, we can have criteria for choosing the right tool.”

The Tool-lover: “Doesn’t that mean we need a sense-making tool? Again, as I told you, we need a tool first.”

The Analyst: “No, this just means that we have to first analyse the context of the context. Let’s focus on that.”

The Developer: “20 lines of code ready while you are discussing.”

The Designer: “That’s a waste of time. But you, developers, don’t have a sense of time anyway.”

The Architect: “Time is an interesting thing. Good you mentioned it.”

The Analyst: “Is ‘time’ the problem?”

The Tool-lover: “We probably need a stopwatch.”

The Architect: “What we rather need is to stop and watch.”

… and so on.

Patterns of Informal Architecture

The CEO was referred to as ‘the architect of the enterprise’ long before ‘Enterprise Architecture’ was coined. The ‘architect’ metaphor was used in 60s and 70s and became quite present in the strategy management literature of the early 80s. And indeed, big part of the job of C-level executives is to manage (different domains of) the architecture of the enterprise. That part is not labelled ‘enterprise architecture’ and probably shouldn’t be. But it must be recognised as such by the ‘formal’ Enterprise Architects. If formal enterprise architecture finds a way to play together with the informal one, this in turn would help the latter understand how to get more benefits from the former.

One way is to use less formal techniques to explain formal EA to the C-level and other practitioners of the informal EA. Storytelling looks like a good way to do that. Another way is to show how formal and informal can go hand by hand and best do it again in a story, the way Chris Potts did in ‘recrEAtion’. Yet a third way is to make it a habit for formal EA practitioners to recognise patterns of informal EA.

It’s not difficult to spot them in processes and cases such as creating/changing chart of accounts or profit/cost centre structure or product/service portfolio. (Or, is it?) Informal EA patterns are also easy to find in any standardization effort or planning a new business capability, opening a new branch or running an integration program after a merger. It’s easy because all those cases have some kind of formalisation, albeit not an EA one. That’s not the case with patterns of informal EA in people relations. But the effort is worth it. Relations between people are of primary importance both for the enterprise and for managing its architecture. This week it was the topic of some very good posts by Tom Graves and Nick Gall. So here, another touch in the context of informal EA.

Formal EA uses models a lot. All models represent certain aspects of the past or the future. (I put ‘as-is’ models in the ‘past’ category as well.) Models of people relations are no exception. Models of the past relations are basically two types: some are based on perceptions and decisions of the modeller about certain aspects of reality and others are visualisation of actual characteristics, registered using some technology:

All models, actual and perceived, belong to the formal EA tool-kit. If we superimpose the two pictures above, conceptual, logical and physical would go to the two ‘perceived’ quadrants, and ‘operational’ – to the ‘actual’ one. What is left is the ‘informal’ relations. They are relations, therefore fall in the EA domain. They work and could be very powerful, therefore are important. Moreover, they are adaptable and can easily cheat the formal one. Here’s an example:

Bill starts a new project and needs a team leader for one of the teams. He has to fill in a request form and send it to the HR Department. Then hope they could come up with the right person from the huge database of employees. Bill doesn’t want to leave things to chance. He calls his colleague and friend Kim and asks him if he knows somebody that has capabilities as that team leader, remember, from the project A which they were involved together last year, but at the same time can handle situations of the type they had three years ago and has that and that technical experience. And he/she should be available for the project period as far as Kim is informed. Kim doesn’t know such a person available but he knows Sarah. Sarah is in a different location. They never worked together but Kim trusts her and has reasons to believe she might be able to help. After a few hours Kim sends Bill a message with the CV of a person recommended by Sarah. Bill gets some specifics of the CV and sends them as requirements to the HR department.

Some may argue that this story is about Knowledge Management, not EA. I agree it’s KM and disagree that it’s not EA. It certainly is and belongs to the grey cloud in the picture above.

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.