Easy design decisions

Of course you know why and how to prevent "meat-ball" designs characterized by no adequate modularity (spaghetti) and no functional separation (e.g. multiple message types combined to one). You don't need an architecture or any standards for that. As a professional designer you just know; it's you craftsmanship.

But are you designing an IT-system and do you have to cope with equally valid alternatives that are not addressed in the overall architecture? And there are no standards defined? Or there is no architecture at all because of the low maturity of your IT-organization? Then these criteria may be of any help to you:

Maximum flexibility (future changes)

Choose the alternative that needs the least effort when requirements change. E.g. if you must decide whether to implement JMS-topics or to implement JMS-queues, prefer topics over queues. Queues can only deliver to one consumer whereas topics can deliver to mutiple consumers. So if - in this example - a second unforeseen consumer pops up, no changes are needed to the system.

Robustness (self healing)

Choose the alternative that doesn't break the system when failures occur. E.g. if you must decide whether to implement durable subscription or non-durable subscription, prefer durable over non-durable. In this example there will be no loss if a consumer goes down for a while; the system recovers automatically when the consumer is up again.

Open standards (lower costs)

Choose the alternative that is based on open standards. E.g. if you must decide whether to use a JMS-API or an MQ-API, prefer JMS over (proprietary) MQ. This makes you less dependent from specific products and suppliers, which improves flexibility and lowers costs. In this example you don't need to change your programs if they must run on another messaging infrastructure.


Of course these design decisions must be challenged against aspects like performance and scalability. E.g. durable subscription may lead to huge databases for the required persistency. But let these aspects be an afterthought and not be leading for the design. First create a design based on the criteria mentioned above and then - afterwards - start tuning the design based on pragmatic aspects; and document why and how you tuned the design. As to-day's limitations need (will) not necessarily last forever, you will be happy to be able to easily upgrade the design when the limitations no longer exist.

Service Oriented Architecture with Java

Are you fed up with over 800 pages SOA-books full of conceptual blah blah? Letting you know it is completely nuts not to implement SOA? Telling you SOA is about business and not about technology, or just the other way around? Outlining huge expensive roadmaps involving every bit of the company? Stressing to you not to start if you didn't restructure your business- and IT-organization in advance?

Don't worry, there is some hope for you. I discovered a mind-sized book of less than 200 pages practical no-nonsense knowledge on SOA; 169 pages to be exact.

The authors clearly have a thorough understanding of SOA from a business point-of-view as well as of the application level implementation aspects. They succeeded in bringing SOA to earth, presenting no more and no less of SOA than it is. In their own words:

We convert the business processes to "services" and expose it to be "oriented" with its business goals. The software design "architecture" that conforms to this is SOA.

Not only does this book offer practical insights in the architectural and business aspects of SOA, why XML and web services is a good idea at the implementation level, the limitations of RESTful services, why using an ESB, aspects of data handling in SOA, and tight coupling (which has advantages and disadvantages) versus loose coupling (which has other advantages and disadvantages). The authors also demonstrate how all of this can be implemented with today's available tools and frameworks in a Java environment. You really can try out at home how these concepts work. For this purpose the Java code snippets used in the book are downloadable from the publishers website.

There is an easy case study included which compares a traditional EAI solution with an SOA-based solution of a simplified business problem. Really a brilliant and yet easy to understand illustration.

If you are a programmer (not necessarily a Java programmer) and you want your SOA-programming understanding to be state-of-the-art, this book is one that should be on your shortlist for reading shortly.
But also if you are a designer or an architect with little or no Java knowledge, the book is still very valuable in understanding when and how to apply an SOA-approach; you just skip the Java details.

As I said, it is not an overloaded book as many others are, but just a mind-sized set of interesting need-to-know knowledge from a holistic point-of-view, business as well as implementation, written in a style which offered me a few hours of delightful reading.

[Click picture for details]

How to model EDA

I got a question of a fellow-blogger, Peter Rajsky, about how to model EDA. He posted about it on his own blog, but he is a bit disappointed that no discussion arose. Perhaps his posting didn't reach the right specialists or nobody gets the clue.

To be honest, I did not spent any effort on this subject either. I promote the event-driven approach, I draw pictures from a conceptual point of view. But I did not (yet) dive into the details of hard core modeling techniques. Which I think I should do, eventually. Not because it's the enterprise architect's task (which I think it isn't), but to learn, to gain deeper insights in the solution design details and to be able to share my deeper insights here on my blog.

Peter puts the following requirements for a modeling technique (extension of UML):

• To be able to define event taxonomy - using class diagrams would be sufficient
• Explicit modeling of outbound interface - interface, which produces events (instead of providing operations)
• To use this outbound interface in sequence and activity diagrams (in the similar way as inbound interface) to be able to model event reactions

Although I cannot mention any tools or techniques around, I published some postings on these aspects before:

• With regard to event taxonomy, the concept of the Canonical Data Model could be in charge.
• With regard to modeling outbound interfaces and event reactions, the concept of a declarative process modeling approach could be in charge.
  

If anyone, especially tool-vendors, can contribute to this subject, please do. We are in need.

And Peter, thanks for initiating the awareness.

About CIOs and the tsunami

I came across a posting called Are More CIOs Getting Fired? by Abbie Lundberg, editor in chief of CIO Magazine.

She talked to Bruce Rogow, who's enjoyed a 40-year career in IT research and consulting, conducts what he calls the CIO Odyssey, traveling around the country to visit with hundreds of CIOs every year.

Since over the last five years new technologies have started to turn the world upside down (e.g. think of the IP-adresses you carry with you in your pocket) Rogow recognized for the first time that the CIOs he's been meeting with have more questions for him than answers.

Rogow likes to visit IT execs who have been in their jobs at least 5 years, but it was as if the bottom fell out on the people in his network, with some 60 percent of them suddenly no longer at their companies.

Lundberg asked Rogow if he thought CIOs were missing the boat on the rapidly changing world. But then she realized it's not so much about missing something that might leave without you; it's more like being on the shore knowing there's a tsunami coming.

According to Rogow there are three scenarios.

Some CIOs are trying to do business as usual. All these issues are coming at them, and they're swatting at them like flies. They're tweaking. They think they can tweak their way into the future, but they're wrong. These guys are vulnerable.

Others are taking a real objective look at what's coming in the next three to five years -- and they're coming back saying "holy s***." This is not "different circus, same clowns,"; it's a different circus with different clowns -- different skill sets and different user communities with radically different points of reference and expectations. This group of CIOs is working hard to figure it out.

The third scenario is reactive. New CIOs come in thinking that whatever the last person was doing wasn't right. They know they were brought in to do things differently. Some are good, but some are getting rid of the enterprise architecture group and decide that users should be able to use whatever they want without understanding cause and effect or the consequences of their decisions. This group is the one most likely to really screw things up.

Interesting posting for every CIO who doesn't like the acronym is coming to stand for "Career Is Over."

Writing lesson on EDA

The frequency I am publishing blog-postings has decreased for a while. The reason is that I am participating in writing a course on SOA. The part I am writing is lesson 6, about event-driven architecture. It makes fun (most of the time) as well as exhaustion (once in a while).

As far as I know there are not very much books published on the subject of event-driven architecture as a modeling approach at a business process level. Viewing the business as a collection of relevant business events that are planned to react upon has not very much been published about.

That makes my contribution to the course a lot of out-of-the-box thinking based on 3 decades of practical expience in the software development field. It is exciting to write down original ideas with the knowledge it will be actively distributed to an interested audience. The readers will be offered deep insights on practical EDA. I am not very much a public speaker, but I love writing!

You might be interested in what I, and others, got to tell. If you understand Dutch you can find more details on this SOA-course here.