Tag Archives: Architecture

Business Activity Monitoring (BAM) and Related Areas

When you work in the software industry you are probably used to seeing things change rapidly. One of the disadvantages that come with this is a “heterogeneous” use of terms. It is often due to the fact that we do not want to bother ourselves with precise definitions. A very sloppy use of language is the natural consequence.

As some people have noticed in the past I tend to speak rather neatly. I can attribute this to my parents who were very much concerned with a correct usage of language (my father used to work as a German teacher after all). So I may be a bit more aware of the implications of an imprecise use of language. Therefore, today I want to look at some terms that are often used either without much differentiation or without a precise notion of the relationships between them. They are

  • Monitoring,
  • Business Activity Monitoring (BAM) and
  • Reporting

Monitoring is mostly used to describe an operational activity that looks after currently ongoing things at an individual level. It typically deals with questions like “What activities in my organization are currently causing problems?”. In a Business Process Management (BPM) context this means checking that all process instances are running fine. An operator will query the BPM system and ask for process instances that failed entirely, exceeded timeout limits for single process steps etc. Also automated activities fall into this category. So if you have set up an alert that alarms a human being or another system if some threshold has been exceeded, I would also consider this as monitoring.

However, we are gradually moving into a grey area here. Depending on the type of the rule that is associated with this alert, the focus moves more towards the Business Activity Monitoring (BAM) area. So imagine a threshold that is not concerned about a single incident any more. Rather it can be of a “composite” nature and look at an average for a certain time frame (e.g. average order amount per day of the week). Such figures are usually called Key Performance Indicators (KPIs). Managers tend to be much more interested in KPIs than in the characteristics of a single, although very important, activity in the organization. So instead of asking “How are we doing with order 5297523?” they would like to know “How is our on-time order fulfillment rate today?” You can think of this as monitoring for operations management. If you want to know how you are doing NOW from an overall perspective, BAM is what you probably need.

Take away the “now” attribute from this and you pretty much end up with Reporting. This answers question like “How was our on-time order fulfillment rate this month?”. In many cases this will be closely linked to Business Intelligence (BI) and Data Warehousing (DWH) topics. Some of the BI/DWH providers have also realized that their customers do not only want to know how they did in the last month but how things are going at the moment. The simple reason is that looking into the past is good to identify structural issues that can then be tackled. However, it does not help to identify a current or upcoming problem and avoid its worst consequences by taking instant counter measures.

Being able to react in almost real-time to what’s going on, is the real value of BAM. The later you realize that something is going wrong the fewer options you have and the more likely it becomes that you can only try to repair damage already done. Although implicitly mentioned in the above paragraph, I want to highlight that BAM is not only concerned with existing but also with upcoming problems. You should expect a BAM solution to be able to identify trends and alert you based on that.

So there are distinct, yet related use-cases for all these functions and you definitely want to combine them to get most from them. I can well imagine that over time these things will, at least to a degree, merge into broader solutions. One last word here: The statements given here can not reflect all possible variations and in your particular case things may seem to be different. Don’t be disturbed by that feeling. Rather analyze the situation and you will probably discover that the general lines are still the same, although the details may vary.

A Comparison of the Top Four Enterprise Architecture Methodologies

Microsoft has published a comparison of the four most well-known frameworks / methodologies / processes that aim to help you with Enterprise Architecture. These are

There is a whole bunch of other interesting articles on this page, so you might want to browse around there a bit.

Business Analyst and Enterprise Architect

In a recent edition of their ZapFlash newsletter the guys from ZapThink (I could not reach their site when writing this, therefore no link is put in here) bring up a pretty interesting topic. They discuss the relationship between the role of a {en:business analyst} (BA) and that of an {en:enterprise architect} (EA). They put them much closer to one another than I would have done prior to reading this, which triggered some thinking on my side that I would like to share with you.

The core point, I think, is that both roles were “invented” in the attempt to link the {en:strategic} layer of the {en:organization} with the {en: operational} one. (Hm, can you think of this as an incarnation of the famous knowing-doing-gap?) This view leaves out completely the notion of business and IT, which would delude things for now. Both sides have realized (or were probably forced to) that in many cases there are significant gaps between what is needed and what exists in reality. So they have both moved from their home territory into “enemy’s land” in order to grab their share of the pie. This has narrowed the gap but not closed it.

What is needed is a role that coordinates and brings together the BA and the EA. It is in my view not realistic (and probably also not desirable) to merge EA and BA into one physical person. But the main problem, from an overall organizational point of view, is that they serve two different masters. They therefore have goals that conflict on a practical level, although the intentions point (hopefully) into the same direction. The result of this combination is that a lot of discussion, negotiations etc. takes place. And at the end of the day a compromise is reached, that nobody is really happy with.

Instead it might be worth thinking about a new organizational layer sitting between business and IT. BAs and EAs would be reporting into the same person and work on the same set of goals. The challenging thing would obviously be to identify those goals. But hey, this is true for all parts of the organization. On a very high level I could think of revenue (coming from the BA side, mirroring how well the needs of business are served) and profit (coming from the EA side, representing how efficient things are). This is certainly just {en: brainstorming}, but it illustrates the point.

An even better approach would probably be to take the line of thinking from the above paragraph and implement it into the existing orgchart. Hm, looks a bit like a matrix organization (anybody out there who really likes them?). Still, saving an organizational layer is certainly worth a reasonable thinking effort.

That’s it for now. I am looking forward to comments on this.

Nicolai M. Josuttis “SOA in Practice”

A colleague recommended this book (link to amazon.com and amazon.de) to me and I was not disappointed. On the contrary, this was one of the most interesting IT books I have come across so far. The author is pretty well known in the SOA space and a regular speaker on conferences. He has a lot of real world experience and this shines through. What made the book particularly valuable to me, was that Josuttis points out when something is not black or white but gray and discusses the relevant aspects.

This book is probably not so easy to read for a beginner, but certainly of great value to the more experienced reader. It does not provide checklists or vendor recommendations but focuses on patterns and a good conceptual understanding. It will therefore not become outdated as quickly as many other publications but probably be relevant for a number of years to come.