There are two ways to omit details in a model, to introduce abstraction:

1. Omitting details you know exist but don’t need now (abstraction on purpose)
2. Omitting details you don’t know that exist (abstraction by accident)

As you can see from the phrasing used, the second type is a dangerous kind of abstraction. If you don’t know the details you left out, you don’t know if you got the abstraction right or not.

You’ll often be in a situation where you just don’t know enough (yet) about the system to be ensure you got the abstraction right or not. In such cases, you are carrying an unknown variable with you in your design process.

That variable should eventually become (sufficiently) known. Once it does, you can revisit earlier made abstractions and verify if they were justified or not and make adjustments where applicable and required.

In any case. abstracting details away when you are not sufficiently aware of what you are abstracting away is a dangerous road to take. It’s the architectural equivalent of proving that 1 = 0 using some sneaky (but wrong) trick.

I often say that “high level makes you fall deep” meaning that if you make high level diagrams (omitting a lot of details) without being aware of the abstractions you are exposing yourself to considerable risk later on in the design and realisation phase.

Recently I heard someone make the statement that you need in describing a system using models, you need to find the proper balance between precise models and flexible models.

In this context, precise models would be models that are correct, are as complete as possiblem flexible models would be models that are less correct but are capable of conveying information to stakeholders (mostly business people).

I would dare to state that above is not correct.

The chapter on viewpoints in the ArchiMate specification, makes a distinction between three types of viewpoints (models):

Deciding Viewpoint. Models in this category are meant for people who need to make decision, decide on trade-offs. They typicall compare several alternatives based on a list of criteria.

Informing Viewpoint. Models in this category are meant for people who need to get or give information on the system. They must be adapted to whatever area of interest and level of interest the audience has.

Designing Viewpoint. Models in this category are meant for people who have to further design and build the system. These people need completeness and precision.

So back to our inital question: do we need to find a balance between precision and flexibility in models describing a system? I say: no. You need precise models and you need flexible models. It depends on what they are used for (deciding, informing, designing) and who they are intended for.

If you insist on making only one set of models, for all stakeholders and for all purposes, there is no end to the amount of damage can you do. If you find yourself deciding on ‘the right balance’ in a model, take a step back and see if you are not trying to model the system using a one-size-fits-all model.

One would assume that a speaker on a Data Management Conference got the distinction between conceptual, logical and physical right? Well … no 

It’s very common to define these terms based on the level of detail they contain. There are a few things wrong with this definition:

First, it completely ignores what we know about idealization. Idealization is the idea that defines terms like conceptual, logical and physical. People familiar with the Zachman framework will recognize this.

Secondly, it’s a very ambigious defition. What if I add a small detail to a conceptual model, did it just became logical? If not, what if I add this other small detail?

These are the definitions I use, based on idealization:

Conceptual Model. A model describing a system where there is complete abstraction of any implementation with an information system.

Logical Model. A model describing a system where we don’t abstract away a realisation with an information system, meaning we have to make design choices, but we still abstract away the technology used.

Physical Model. A model where neither the fact it is implemented using a particular information system nor the technology used, is abstracted away.

You can still have ‘very detailed’ or ‘high level’ if you want, since that is ortogonal to the above. You can have a high level physical model or a very detail conceptual model.

When you want to hire someone, you are looking for some particular skills. I call these the primary skills. Any person you hire, any person in your team, also comes with a set of secondary skills. Secondary skills are skills you weren’t specifically looking for but you got them anyway.

If you are looking for a Java developer, you are looking for someone with ‘Java development’ as a primary skill. The person you hire, might also have experience in C# development, project management or Linux system administration. Those are the secondary skills you got even though you didn’t ask for them.

In my experience, it’s dangerous to structurally use those secondary skills in your team. Sure, when an immediate fire has to be dosed, being able to call on these secondary skill might be a life safer, but if you start depending on them structurally, you are putting yourself at some serious risk.

What is the risk? We have those skills, it would be a shame not to use them!

Well, let’s assume you have been using those secondary skills on a structural basis: one of your Java developers is not only developing code but also has been doing some of the project management and is administrating the local build and version control Linux server.

One day, that Java developer comes to your office and says he is leaving for a new job. Or perhaps something less permanent: you get a call telling that your Java developer has an accident and won’t be able to come to work for 4 to 6 weeks.

That is when you start having an issue. You find yourself on the market to find a (temporary) replacement that can develop in Java, has project management skills and knows how to administer a build and version control Linux server. You are looking for a very specific snowflake. Good luck finding that!

That is the risk of structurally using the secondary skills. You are creating unique snowflakes in your team that are very hard to replace. The only way to avoid this risk, is not to use the secondary skills available in your team. That might sound counter intuitive to some people: not using skills that are present in your team while you need them. Yet, it is the safest way to avoid having to replace a snowflake 🙂

We all know the idea of Buzzword Bingo. You create a matrix filled with so-called buzzwords and when, during a meeting or speech, you hear one of the words, you tick it of. When you reach a certain number of ticked words or have filled a row or column, you call out “Bingo” or “Bullshit”.

When you look at common buzzword bingo matrices, the words actually seem pretty normal. So what is so “bullshit” about them?

When a person uses a word, it can be in one of two circumstances:

1. The person is familiar with the subject
2. The person is not (sufficiently) familiar with the subject

Case 2 is an example of Cargo Cult, where someone mimics, without understanding why, the behaviour (the use of certain words) of people they see as successful, hoping to achieve some of that success as well.

The listener can be in the same two situations as the speaker. Since the proper or improper use of a word is in the eyes of the beholder, or better said, the ears of the listeners, we end up with the following four situations:

1. The person is familiar with the subject and finds the word is used properly
2. The person is familiar with the subject and finds the word is used improperly
3. The person is not (sufficiently) familiar with the subject and considers the word improperly used
4. The person is not (sufficiently) familiar with the subject and considers the word properly used

If we put these two lists in a matrix, we get 8 different combinations.

Of these 8, there are 3 combinations that could spark a Buzzword Bingo: combinations #3, #4, #7 and #8. But only 1 of them is a genuine Buzzword Bingo where the listener does not embarrass him- or herself: combination #4.

In combination #3, it should be a constructive debate on the use of the word. Both people are familiar with the subject and could experience a valuable learning opportunity. In combination #7, the listener would only embarrass him- or herself. Finally, combination #8 is the saddest case, both parties are not familiar with the subject and both embarrass themselves.

It should already be clear that playing Buzzword Bingo is a dangerous game, one in which you are more likely to ridicule yourself than anything else.

Sadly, it is even worse. As we learn from David McRaney in his book You Are Not So Smart, people have a strong tendency to think they are smarter than the average. They think they are in combinations #3 or #4 when in reality they are in combinations #7 or #8. That’s why people love to play Buzzword Bingo, they honestly think they know better, they honestly think they are right and the speaker is a clueless person.

Reality is sobering: you are as stupid, or as smart, as the person you are listening to. So if he is using a term you think is a useless buzzword, it is probably as much you who doesn’t understand the word as it is him performing a ritual in his cargo cult.

Introduction

As an independent consultant I operate from my own one-man company. That means I am participating in the world of invoicing. In the last couple of years I have seen a steady rise in electronic invoices. Before electronic invoices I received all my invoices in my letter box and believe me, compared to electronic invoices, that was easy and cheap. In short, I don’t like electronic invoices.

The most important downside is that they don’t arrive in my letter box. Most providers of electronic invoices offer me a portal where I can login and download the invoice. Of course, every single one of these portals has its own registration system, its own credentials and its own password polices. Needless to say, it’s very cumbersome to fetch invoices. Most of the time I end up ‘logging in’ through the ‘password forgotten’ use case. I don’t even bother to change the generated password since next time I’ll be logging in through the ‘password forgotten’ use case anyway.

After taking the first hurdle, logging in to the website, I am greeted by the second one: user interface and functionality. Some look nice, some look like a website that would have been great in 1994 but not so anymore in 2013. Tastes differ so I’ll assume it’s me. But in terms of functionality, some of these portals seem to make it a sport to provide the worst possible user experience in finding and downloading invoices.

They also differ greatly in what kind of functionality they offer. There are portals that offer me an online archive (although there is no mention whatsoever about any long term guarantees of the archive existence). Others encourage me to download the invoice as soon as possible since they only offer access for a limited amount of time. Hint: since not all of them offer archive functionality and since I can’t afford to have an archive of invoices scattered all over the internet (with varying service level agreements), I can’t make use of those archives anyway. Whatever functionality they offer, in my world they are just temporary inboxes: I download the invoices and archive them locally as soon as I can after which I forget about the copy on the portal.

All sources of electronic invoices notify me through email when a new invoice is available through the portal. One source even is so kind as to include a direct download link in the email. Convenient as it may seem (and it really is) it’s also a security risk: the direct download link does not require any form of authentication. It acts like a ‘bearer token’ with a long life span, a token that is transmitted in clear text as part of the email and can be intercepted.

Current Architecture

All this is the consequence of one-sided view on the problem by publishers of electronic invoices. If you look at the challenge of issuing invoices from the point of view of a company, the architecture below is an obvious solution. Invoices are generated internally in a digital format, they are distributed using a portal and the company can even track which invoices have been accessed and which haven’t.

If you take the point of view of a customer and assume the same architecture as above, the picture looks different and a lot less shiny. We see that a customer is faced with dozens of point-to-point access paths to invoices, all of which are implemented differently and act differently.

Better Architecture?

As an architect I feel this can be done better, a lot better in fact. In my proposal for an architecture, there are four roles involved in getting electronic invoices from a publisher to a customer: (1) Customer, (2) Collector, (3) Distributor and (4) Publisher.

The primary function of a Collector is to collect all invoices for specific consumers and make them available to those consumers. The role of the Distributor is to collect invoices from publishers and route them to the correct Collector so they end up at the correct consumer. The main goal of the Collector and Distributor is to cater for their respective customers: Customers and Publishers. That is a significant difference from the current architecture: both stakeholders (Consumers and Publishers) have a party who will act in their best interest as catering them is their reason for existence. In the current architecture no party exists which will do their best to cater the Customer. Of course, Publishers may say they do when they offer their portals but reality is that it’s not their primary reason for existence and the above mentioned problems prove that they only go so far in providing services for the customer.

In my specific case, I could opt for a Collector service that prints and mails the invoices to me while at the same time keeping an electronic archive for me.

In Belgium you have a few services that seem to be offering services related to the Collector role: ZoomIt and Unified Post. If you look at their websites and service offerings it becomes obvious their primary focus is on the publisher of invoices and not the customer.

Last weekend I registered for the European Identity & Cloud Conference 2013 organized by Kuppinger Cole.

The agenda looks very promising with topics like:

1. Managing Identities and Access to Information for Cloud, Mobile and Social Computing
2. Privacy, Data Protection, IT-Law
3. Cloud Governance
4. Beyond BYOD, IT Consumerization & Mobile Enterprise
5. Life Management Platforms, Personal Data, Customer Managed Relationships
6. The Internet of Things (IoT)
7. (Big) Data Governance/Stewardship
8. How to Build your IAM/IAG Infrastructure the Right Way – and Support Business Today

I can’t wait until May and hope to see some of you over there!

Most of us are familiar with a famous quote from the movie “Devil’s Advocate”. If it was Devil’s Architect, it would sound like this (adaptation by me):

Let me give you a little inside information about Solution Architects. They like to watch. They are pranksters. Think about it. They give project managers architecture descriptions. They give them this extraordinary document with rules, guidelines and decisions, and then what do they do, I swear for their own amusement, their own private, architectural gag reel, they set the rules in opposition. It’s the goof of all time. Build but don’t couple. Couple, but keep separate. Separate, but watch dependencies. Ahaha. And while project managers are jumpin’ from one foot to the next, what are they doing? They are laughin’ their sick, fuckin’ ass off. They’re tight-ass. They’re sadist. They’re an absentee landlord. Follow them? Never.

Here is the original:

Let me give you a little inside information about God. God likes to watch. He’s a prankster. Think about it. He gives man instincts. He gives you this extraordinary gift, and then what does He do, I swear for His own amusement, His own private, cosmic gag reel, He sets the rules in opposition. It’s the goof of all time. Look but don’t touch. Touch, but don’t taste. Taste, don’t swallow. Ahaha. And while you’re jumpin’ from one foot to the next, what is He doing? He’s laughin’ His sick, fuckin’ ass off. He’s a tight-ass. He’s a sadist. He’s an absentee landlord. Worship that? Never.

02/10/2010: after posting this, there were some insightful comments made. I encourage you to read them as well.

I am generally very enthousiastic about ArchiMate. What is not to like? It produces elegant models that are easily understood by a broad family of stakeholders and the viewpoint categorization is refreshing and very useful, especially compared to for instance TOGAF 9. It’s not all sunshine however, there are for instance a couple of points in ArchiMate where I tend to differ in opinion with some fellow architects.

One of those points are the assignment relations between the application layer and the business layer as shown, using bold red, in the following subset of the ArchiMate 1.0 metamodel.

Before I go any further I have to state this disclaimer: I will explain my point of view given my current understanding of and experience with ArchiMate. If you have any remarks, negative of positive, on the reasoning presented in this post, I would appreciate if you would post a comment or contact me directly!

Metamodel (click to enlarge)

According to the specification (see Chapter 7 “Cross-Layer Dependencies”) these relationships have the following meaning:

Assignment relationships, between application component and the different types of business behavior elements, and between application interface and business service, to indicate that, for example, business processes or business services are completely automated.

In short, in case of complete automation, you assign active structure from the application layer to the business behaviour instead of the, usual, active structure of the business layer (actor and role). With this active structure from the application layer, an application component, comes the external structure, an application interface. The application interface will be the interface through which clients use the business service.

Let’s develop a small and simple example where we use these relations, explore their meaning and identify potential pitfalls.

A company offers a customer support service to their customers, this service, “Customer Support Service”, is realized by a business process “Customer Support Process”. This process is executed by the customer support department who offers a phone interface for customers. The process itself is fairly simple, first the support request is analysed, then a knowledge base is searched to find possible answers, the possible answers are combined into a support answer for the customer.

As you can read in the process description, the actors in the customer support department use a Knowledge Base application. They access it through a web interface. This application offers a service where you can browse and search common problems and their resolution. The customer is not directly exposed to this Knowledge Base application. The model belows shows these elements and their relationships.

Example #1 (click to enlarge)

We haven’t yet used the assignment relations between the active structure of the application layer and the behaviour of the business layer.One way to introduce them is to simply state that instead of offering this service using the customer support department, it is completely automated with direct access to the Knowledge Base application. The Knowledge Base application is capable of performing a simplified version of the Customer Support Process and the customer directly accesses the web interface. The business process has to be simplified before it can be completely automated. Our Knowledge Base application is not, as most applications aren’t, capable of intelligent analysis of the support request or possible resolutions.

Example #2 (click to enlarge)

The above simplified situation, with only a completely automated realization of the business service, is not very common. In most cases the customer can use both interfaces. The Phone interface is offered for customers who are unable or unwilling to use the web interface or whose questions are just too complicated and require a customer support representative. The web interface is offered in case the customer has access to the Internet and is able and willing to use the direct web interface. At first sight we can simply model this as seen below.

Example #3 (click to enlarge)

But is this correct? We have an application component whose internal behaviour is represented by a business process, it completely automates the business process, But this process behaviour itself uses an application service that is realized by … this very same application component! That sounds pretty much like an endless loop. I don’t think it is impossible as such, depending on the level abstraction level of the process definition or the level of composition of the application component, you could defend the above model. But honestly, I feel it would barely represent reality.

It is clear that we want to avoid having a business process that uses an application service that is implemented by an application that itself completely automates that business process. Yet, the situation with two interfaces to a knowledge base, one offering access through a customer support representative and one offering direct access to the application, is very common. Both interfaces support the same buFsiness service, they both fulfill the same customer need. We can’t use a single definition of internal behaviour though, so let’s update our example and define an extra business process. This new process is a simplified version of the original process that only allows simple questions and is therefore easily automatable. This new situation is shown in the diagram below.

Example #4 (click to enlarge)

The above example has been kept as simple as possible. In practice it would be unlikely that the original web interface of the knowledge base application would be considered usuable by customers. In most situations you will find a new application that offers a more suitable interface for end users, this application will use the original knowledge base application through an application-to-application interface (this interface is not shown on the model).

Example #5 (click to enlarge)

These simple examples show my current understanding of these particular relations in ArchiMate. If my understanding would be incomplete or even flawed, I hope to find constructive comments to enlighten me.

Recently I came across an excellent article on One Trick Ponies in the world of architecture. One trick ponies who know only one type of solution and desperately try to make that one the only possible solution.

This part of the article made me smile, especially since it perfectly describes my sentiment after a situation I experienced not so long ago:

Now while I look down on these people, because lets be blunt they are lying in an attempt to secure a project that they aren’t qualified for based on the hope that they can somehow pull it off. (A dazzling example of managing risk … upwards!) Why people do this I’ll never know it ALWAYS ends in tears. But I guess it keeps the cash flow going for a while.

My personal experience involved an external expert who insisted that, for a simple Java project, storing data in a database on an IBM System i would be impossible, it would cost enormous amounts of money to access and integrate this “legacy mainframe” from the Java world. I challenged the expert and asked him what kind of database was used on an IBM System i. An awkward moment of silence followed. The IBM System i uses DB2, a well known and proven database technology, it is extremely easy to access it from a Java program. In fact, developers won’t even notice the difference between the System i DB2 instance or a Windows instance.

This expert tried to guide a company towards a more expensive solution simply because he was more familiar with it. The IBM System i DB2 solution was unfit because he could not be part of it.

Of course, no architect can know every piece of technology or platform. You are bound to encounter something you are unfamiliar with. But if you do, be a professional architect and investigate, read up on the basics and find knowledgeable people inside the company who can help you fill in the details.