Tag Archives: BPM and SOA

Lifecycle Management with SOA and BPM: 1+1> 2

For some time the topics of SOA Governance and BPM have been looked at as if they were two relatively unrelated things. And this perception is correct in the sense that you don’t have to have them together. However, more and more people realize what huge additional benefits are in for them if they combine the two things. In many cases the idea is that you need some logic to govern the actual work (design, development, testing etc.) for a process that has been modeled in a nice fancy tool.

But you can also do it the other way around: Think about what you would get if you could govern your whole IT lifecycle management from one tool. The idea goes like this: You store all relevant information about “objects” that are relevant for your organization in a central repository, and the different attributes that describes those objects (aka assets) are completely freely configurable. You probably need to attach additional information to them, like existing documentation etc. So in a way you can think of these information in the repository as a way to store the knowledge about all relevant aspects of the organization and then leverage this knowledge.

Now based on that groundwork, whenever a request for a new a feature in the IT landscape comes in, you can have it go through a “workflow”. The first steps would probably be about an approval chain. So people from various functions (e.g. product management, operations, security, marketing etc.) would need to either approve or reject this. How the final outcome is determined can be a bit tricky (and is much more a political topic than a technical one).

Then come steps like gathering requirements, signing them off, doing the development etc. You probably also want to integrate this whole thing with your development chain (automated testing, continuous integration etc.). At any given point in time you know where your development stands in terms of the project plan.

So if you step back a bit and look at what you get, we are not talking about development tools any more. Instead this is true, real-time end-to-end visibility. There are clear responsibilities for assigning tasks (a human being has to decide on something) and you no longer need to fear emails that are lost in the inbox of someone’s email program. Instead you get a view into the currently open tasks, their due dates etc. Other advantages existing but for now those are the critical ones. The reason for this is that these functionalities allow you to have automatically generated documentation that satisfies your compliance requirements. In most organizations these things eat up enormous amounts of resources and affect processes that should deliver value to the organization.

Let’s leave it here for now. I am quite interested in your comments on this, so please let me know.

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.

What is an Enterprise Service Bus (ESB)?

If you all too often hear the term “Enterprise Service Bus” or ESB (we all love those acronyms, right?) but never really knew what it’s all about, you should check out this recording by Marc Richards. He gives a great overview what an ESB is at its core. Rather long but worth every minute!

What I particularly like about this presentation is that it’s completely neutral with regard to technology or vendor. Instead Marc explains what an ESB is supposed to do, but not how this is implemented. The term ESB (at its very core) is a concept and neither a technology nor a product can claim that they are the only rightful incarnation. So statements like “An ESB must be BPEL-based” only demonstrate a fundamental lack of understanding. You could also have an ESB based on CORBA running on a mainframe. Well, this will probably not happen too often but it underlines the point.