"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?"
Comments (2)
Written by
This e-mail address is being protected from spam bots, you need JavaScript enabled to view it
on 13-09-2008 13:41
Hi Jack I agree with you that it is very hard, if not impossible, to convince people with a completely different agenda of the necessity of sound architectural decisions. But to my opinion, that should not be necessary! Every program or project should have some form of Design Authority that needs to give its blessing to the architecture under construction. Without the signature of the DA the program or project will not continue. This way of working gives the lead ITA the authority they have to have and prevents lengthy discussions. You're not a sales, after all, are you? On the other hand I'd like to warn you that an ESB is not the solution to all your problems in all cases. I have recently been involved in a project the goal of which was to replace a fully optimised 70% batch oriented mainframe application by a distributed SOA system, complete with ESB and process server, multiple loadbalancers, various pieces of software. In this case the advise of the lead architect should have been "DON't DO IT!", that is not for the whole application - only replace those pieces that lend themselves to interactive service oriented processing! This would have saved all parties many nightmares!
Written by
This e-mail address is being protected from spam bots, you need JavaScript enabled to view it
on 26-09-2008 18:25
Hi Lydia,
You are right. Everything must be challenged and viewed from its own perspective. Completely replacing older systems "mostly" is not the best option. But sometimes it is. And if you decide to replace legacy or part of it I would advise to use an ESB solution. The ESB is not only the SOA-platform, but also supports visibility of the application landscape and connectivity between systems. All in a standards based way that is - for the first time in history at the application level - supported by ALL vendors. If you don't, you will get into trouble sooner or later.
Via Nova Architectura is not responsible for the content of blogs, but authors and readers are asked to adhere the following guidelines. Authors are strongly encouraged to check facts, cite sources, present
balanced views, acknowledge and correct errors. Respect copyright, fair use and financial disclosure laws. Please do not disparage organizations, or individuals. Being critical of someone's practice is acceptable, when it is done in a professional manner. Prevent usage of marketing statements. Comments should be relevant to the specific post they are attached to. Spam, flaming, personal attacks, and off-topic comments are not
permitted. Readers are requested to notify
This e-mail address is being protected from spam bots, you need JavaScript enabled to view it
of any violations. The editor holds the right to remove any statements that, in the editors opinion, infringe the above guideline(s). The author receives a notification of this action.
