Monday, June 02, 2008

Justifying SOA and ESB, how not to...

"Jack, I got this project where we are rethinking the structure and integration of our itinerary planner with other applications. You guys keep on telling to go for SOA and ESB. Could you please take some time for a cup of coffee with me and explain me what my benefits could be?" That is what one of our projects leaders asked me a couple of days ago.

"Of course, I would be happy to" I answered her. And that was true. As I am an architect, I love to talk about structures, flexibility, composition, interoperability, efficiency, integration and innovation.

I started drawing pictures and explained them to her at our date last week. She came up with a diagram of components and I was happy to see that her project members created a modular design. I explained to her where to put the ESB in place and I told her that the modules were fit to be implemented by the open web services standards. Sure, this is not an SOA yet, but it is a good first step. Especially in an IT-organization like ours, that leans a lot on organic evolvement rather than strong governance.

And then she said: "Wait a minute, Jack. I did already some inquiries in advance to find out about the costs to make use of the ESB and implement web services technologies. And believe me, I was not very amused when the Competence Center of Integration came up with a preliminary estimation."

She continued: "Can you tell me how I can justify these costs? I have to present a business case with a reasonable ROI to our board and this ESB and SOA stuff isn't going to help me. Unless you could tell me where it makes things cheaper."

I tried: "It is not that building your system will be cheaper, but it will make changing your system afterwards much easier. Your system will be much more flexible. That makes the difference."

"What changes do you have in mind?" She asked me unfeigned.

I felt uncomfortable. "I don't know. Adding new functionality, breaking up the system, reusing and sharing services in different contexts. That kind of things." Pearls of sweat started tickling my bald forehead. The conversation went into an undesired direction. "Hurry Jack, find a metaphor, quick" I thought by myself. My crashed hard disk of a few days before came to my mind and I started to rescue my soul.

"Well, an ESB is like the motherboard of your PC. And the services are like the components plugged onto the motherboard; power supply, storage, memory. A few years ago I bought my current PC. It was a high quality (I mean expensive) one. It had a lot of memory, 512MB. The hard disk had 160GB of storage. More than I would ever need. I couldn't imagine why I should have more. After one year, already, I ran out of storage. The only thing I had to do was to go to the local store and buy an external hard drive. I plugged it into the USB port and within seconds I had doubled my storage. And then I needed some extra RAM. Same story, just plugged it in and it was doubled. I didn't predict these changes but they came. And last week, my hard disk crashed. I was very happy that I could easily remove my old hard disk from the computer by unplugging the little connectors and that I could just as easy plug a new one in. And more, there was even space the easily add an extra hard disk drive to write my back-ups to. The PC could have been build smaller and cheaper if it wouldn't have all those tiny standards based connectors and cables, if the components were soldered directly to the motherboard." Was that true? At the same time I thought of my laptop which I couldn't extend easily, but which was very convenient for its mobile usage. Wrong example?

She dropped her pencil, enclosed her cup of coffee with two hands and sipped. She stared at me without saying anything. I mean she did not talk, but her body language was shouting: "Dear o dear..."

The lesson I learned was: Don't try to convince system-scale project leaders of enterprise-scale architectural decisions or you will "die". Especially if you don't have good examples at hand. (Should project leaders be "convinced" of architectural decisions at all? Or should there be a "trust" relationship with the employed architects? Subject for another blog entry.) The smaller the project-scope is, the more the wavelength will differ from the enterprise level architecture. A project leader focuses on delivering in time and within budget. He or she won't be seeking to invest for long term flexibility to cope with obscure future changes, unless this is a project requisition explicitly stated by the paying customer.

"Maturing our enterprise IT? What the heck, I got to deliver a working system within three months and within 150k euro's. Can you help me, mister architect?"


Rick Mans said...

Building a business case around SOA is in my opinion one of the most difficult things to do in a project.

Anonymous said...


Even when the business case is solid, getting the business (and sometimes even the rest of the IT "old guard" to accept it can be a real challenge. Many times it's a matter of shifting the mind set from tactical to strategic - something that comes naturally to most architects, but can be very difficult for others to adopt.

Unknown said...

Haha! I made this mistake once or twice. The mistake I made was trying to help the dev lead solve their problem in a way that would also solve my problem.

Mike Kavis said...

SOA can not be justified by a single project (unless the project is a huge reengineering effort). Implementing SOA should be a strategic, not a tactical decision. Nobody would recommend establishing an enterprise architecture to solve one project's requirements. The same should be true for SOA. SOA pays off in the long haul. That's why you have to go to the business with a portfolio of projects and a SOA roadmap. This is also why I keep screaming that you need to have BPM as part of your SOA stack. The business understands business processes, they don't understand ESBs

Jack van Hoof said...

I agree with you Mike. Though, our problem is that the individual project leaders got ALL the power, even over the enterprise architects. And, worse, they are supported in that by the steering committees (involving management). The enterprise architects are neither supported by a strong governance nor by an own chair in the management team.

To cope with this situation I recommend an innovation budget assigned to an innovation project, where a dedicated and highly authorized project leader has the responsibility to implement enterprise architectures, including SOA.

Any other suggestions?


Anonymous said...

That’s when sponsorship by the company’s CTO/CEO comes in handy. Also a project like this should be part of a larger program in which SOA should give a strategic advantage.

It is important as an architect to envisioning oneself as the project leader and ask yourself the question “what’s in it for me”. No sufficient answers… then you have a very interesting challenge ;) As with every other strategy it should have value at every organizational level of the company.

Gerry Hatrić said...

I think a concrete business case like replacing tons of custom integration plumbing code is much easier to sell than the very abstract BPM will solve all your company's woes.

Some more considerations here: