While delivering a talk on SOA I’ve asked the audience the following question, “What do you think is the driving force for implementing any technology or architecture in a decent size Enterprise?” The answers were typical – better code re-usability, accessibility… But I was looking for a different answer that has nothing to with technical merits of any technology. Based on what I see in the real world enterprises, the main reason of implementing SOA (or any other IT initiative) are career goal of individuals working in this organization.
People want to become more visible and move up the career ladder. Implementing SOA across organization can make enough noise to move them to the next level.
SOA Ground Up
The SOA in your firm can evolve from the ground up. For example, an ambitious architect attends conferences, goes through training, reads white papers, and now he truly believes that SOA is a right way to go. He’s aggressive and influential and managed to convince the CTO or CIO to allocate funds for this.
If you are not an architect but just a software engineer, you may try to start convincing your application manager, but typically application managers don’t want SOA. They are busy with business as usual: do not forget to call into the change management meeting, fix yesterday’s production bug, deal with an offshore team, attend 5-6 meetings a day… They are firefighters. Imagine a firefighter that is putting out a fire…Here you come in a clean white suit offering to sell some new bells and whistles for a fire truck…
The chances of a software engineer to start SOA movement are very slim, really.
SOA Top Down
Another reason for SOA is this: your CIO went to a conference and attended a presentation of an energetic speaker, which clearly explained benefits of SOA over any existing architecture. This is the worst case. Subordinates will not resist – they also have career goals…
Your CIO will come up with an SOA project plan based on available funds and resources, which means that this project is doomed. The fact that your CIO will never admit that it was a mistake makes things even worse.
All application groups will roll up the sleeves, will work hard and meet the deadlines.
But let me remind you a quote from a must read book “The Mythical Man-Month ”:
An omlette, promised in two minutes , may appear to be progressing nicely. But when it has not set for two minutes, the customer has two choices – wait it or eat it raw. Software customers have had the same choices.
The cook has another choice; he can turn up the heat. The result is often an omlette nothing can save – burned in one part, raw in another.
SOA as a burner
The third reason for implementing Enterprise SOA is to burn some cash: we (IT) have $2M – let’s service-enable all of our applications by the end of this year. Why $2M? It’s elementary, Watson! Because you need to burn $2M this year, otherwise you won’t get funding next year. Get some high-price items. Who cares that no real feasibility study was made? Just go with a well known vendor and get expensive software/hardware – your developers will figure out how to plug in that Enterprise Service Bus into your SOA.
SOA Maturity
I work as a consultant, and sometimes I have to interview technical managers to figure out if SOA is a realistic solution for their company, and how the CUSTOMERS of this particular silo application will benefit from implementing SOA in the firm.
What do I see – all these people are working hard to fulfill their current obligations, to make sure that their applications are up and running in production, that support calls are answered in a timely manner, the offshore team is delivering, and on and on and on. And her I come in a white suite asking all these smart questions:
”How do you run business today?”
“What parts of your application are the candidates for being converted into services? No, SOA is not the same as Web Services”.
And these polite but tired people are looking at me, listening to me, they’ve seen already other architects trying to change the way they do stuff in their organization. Several similar initiatives have failed before, and here we go again…I can not forget one technical manager – this lady was having hard times even finding time for meeting with me. During the appointment she was polite, but looked tired and worn out. She’s a professional and was trying to answer me questions anyway, but her phone rang off the hook, he right hand was moving the mouse over the MS Outlook screen. “I’m so sorry, I need to take this call…” And I’m thinking to myself, ”What am I doing there? Does she needs SOA?”
Is your organization ready for SOA? Does your company have the right skills, infrastructure, SLA, SDLC in place? What methodology are you planning to use to identify services?
Do you have lots of third-party shrink-wrapped applications?
You know how to wrap up your CICS application into a Web Service, but are your mainframe developers willing to get re-trained? What about the governance?
Some architects start with purchasing expensive software and hardware assuming that the main part of the SOA initiative is accomplished. No, you can’t buy SOA.
Someone has to do a feasibility study for your firm (preferably external vendor) – but this has to be an honest opinion of a qualified group of people. This study has to be convincing, it has to show if implementing SOA is the right choice at this time for your firm.
SOA maturity assessment is extremely important.
Technical Benefits of SOA
If someone will create an inventory of all applications of a large organization and the data exchange between these applications, it may look scary.
An app A provides data to app B. It would be nice if the app A would be able to easily send the same information to applications C and D as well, but this would require some data transformation. Currently, your people would just create and deploy a new ETL (extract-transform-load) processes for A2C and A2D data exchange.
But SOA can offer you a more elegant way by implementing an Enterprise Service Bus that would take care of the data routing and transformation. Someone said that the main reason for implementing SOA is reusability? Let’s look at the before-after SOA diagram:
The second diagram looks much better than the first one, but how much it’s going to cost your firm to switch from the first diagram to a second one?
How much would a reusable service cost you comparing to just writing new ETL scripts for each new connected pair? Is it worth the money?
Why reusable components would be expensive? Let’s talk about infrastructure, which is an enterprise level group that owns shareable software and hardware.
ESB Infrastructure
ESB requires a centralized group with proper skills. How this group will be funded (a slice of each project’s budget, internal consulting, a hybrid)? SLA must be in place that would require this group accommodate every application team’s needs in a timely fashion. The quality of service has to be clearly defined (is it 24×7 or what’s the max time the service can be down).
Do not forget about service versioning, which is not the same as application versioning. Some service consumers may be happy with the version 3.2 and you’ll have to support both 3.2 and 3.3.
Coming back to the human factor – do you have good relations with the ESB group? Personal relation will always get you farther that any SLAs combined. By the way, Joe Smith who runs the ESB group has his own career objectives and ambitions
The ESB group has to accommodate application group’s needs in a timely fashion. You need to make sure that Joe find time in his busy schedule and allocate his resources to your project’s needs.
If you keep your ugly point-to-point ETL way of connecting silo applications, you do not need to create this infrastructure and introduce yet another moving part into your rather complex enterprise architecture. Again, human relations between you and Joe Smith become crucial for the success of your SOA project.
Now you need to get trained and spend some time preparing your data for the input into the ESB in the proper format, specify the right output format for every new application and document it according your firm’s SDLC process. How quickly the infrastructure team will write and test the conversion script for your recipient application?
Yes, every new connection between the applications that you introduce adds a bit more spaghetti to the diagram, but you could have done all this with your own resources in a controlled timely manner without missing deadlines and jeopardizing your career. By the way, Joe Smith from infrastructure has his own career objectives. If your project fails, your yearly review suffers, now you need to find common grounds in achieving yours and Joe’s personal goals.
To SOA or not to SOA
This does not mean at all, that I do not recommend you to implement SOA in your enterprise, it just means that you need to be prepared and armed when it comes to dealing with all these issues. SOA is definitely a way to go in green field situations when you start automation of your enterprise from scratch.
I wonder if you are familiar with this diagram:
This is Minard’s Diagram of Napoleon’s March on Moscow of 1812. The width of the line shows the size of the army on the way to Moscow and back.
Napoleon was expecting greetings from Moscow authorities, but entered the abandoned and burnt city with no supplies and food for his huge army. His retreat was also a deadly enterprise because of an extremely cold winter (−36 ° F ), no grass for horses (most of them were eaten by the French soldiers anyway). You can read more about it in Wikipedia.
My message to you is this: “Do not repeat Napoleon’s mistakes in your SOA journey. Do not start it unless you have the right expectations and your infrastructure will definitely be ready.
Making Business Users Happy
Oh man, I almost forgot about your business users! Will they happily greet you at the gates of their cities? How did you convince them that they should shell out a substantial chunk of money for implementing your SOA initiative? Do they actually know about this initiative or you managed to get funding because you play gulf with the CEO of your firm?
If this is the case, I have bad news for you – you can’t avoid contacts with business user during immersing your enterprise into SOA waters.
Do they give a damn about what architecture you use to give them the data? Not really. They will definitely ask you a simple question, “OK, I’ll give you X amount of dollars and allocate resources for a year for your SOA project. Will I run business differently a year from now? Will you provide me more analytical data in a more convenient form? Will my customer-facing sales force become more productive which will translate to more sales?”
SOA+RIA
To make end users more productive, we need to shift gears a little bit and recall that user experience really matter.
Think of iPod. How many people know the name of its competitor? What do you prefer – Apple’s iPod or Zune from Microsoft?
The Zune has a bit more functionality, but iPod looks nicer and the user interface is cleaner. InformationWeek has published an articles listing 8 alternatives to iPod . Have you even heard of them?
Tomorrow, huge number of people hopes to get a hold of the new Apple’s widget called iPhone. They want it now. $600? Not a problem. They want it now. Let me stress, it’s still a phone with the ability to browse the Web and a modest disk space for storing music. From the services perspective is not a revolution, it’s the User Experience that make it stand out and this is the main reason why people want it.
You may ask, what all this has to do with SOA? People like nice looking gadgets, and they like nice looking program interfaces too! It’s easier to sell SOA to your business users if the SOA client applications are convenient and slick. Especially this is true for the customer facing applications. If you sales representative comes to a prospective client with a rich-looking application clearly showing your products, their job becomes a lot easier. If you offer your firm’s financial analysts rich GUI interface with live chart and graphs to easily compare performance of two mutual funds, analysts will really appreciate it. You still need to program the services that will go and get the data, but having great presentation layer is extremely important.
When you create or modernize your application, do not just think about powerful multi-processor servers, multithreading, and ESB. Start redesigning the users experience – it has to be available everywhere (at home, on the road and in the office), it has to be responsive, and it has to look better than client server application written it was ten years ago in Visual Basic and PowerBuilder.
Ten years ago we were thinking screens not servers. And this was not a bad idea. When Java was born, the client programming became complex, besides, Sun Microsystems and IBM wanted to sell server licenses, which has moved most of the Java development to the server side.
RIA
Now we can talk about the rich Internet applications (RIA) that can and should be used as consumers to the services. The RIA term was coined by Macromedia back in 2002. I’m not sure if there is a formal definition of this term, but you can think of RIA as desktop-quality applications delivered over the Web with no (or close to none) installation required.Let’s turn on the time machine and go 20 years back. Mainframe with their dumb terminals dominates. The client portion of the application is a black screen displaying green and red text. Then, in the early ninetieth client-server application came about. The clients were not dumb anymore, rich looking GUI that utilized the processing power of the PC.
In mid 90th, Internet became popular. Plain looking pages had an ability to get all kind of information from a plethora of remote servers. From the GUI perspective, it was a pushback. Mainframe had black background with green letters, while Web pages had colored backgrounds, static pictures and the same text fields, buttons and rudimentary HTML tables.
Now the rich GUI is coming back again in the form of RIA. These are not page-by-page typical Web site, but full-fledged applications with rich controls, audio and video, with state stored on the client. Now the user get this nice looking application delivered to their PC without the need to go through a complex install process.
Today, RIA can be created with Adobe Flex or AJAX. Microsoft’s Silverlight is coming out later this year, and Sun Microsystems will offer their JavaFX RIA solution in 2008. OpenLaszlo can also be used for creation of RIA. All these technologies can be used for creation of consumers of the services in your next SOA project. Leading enterprises started using professional designers for wire-framing next generation Web applications.
If you are an architect of an enterprise SOA project, do not just think servers, clusters, and grid computing. Think of your business users. Give them something nice, and they’ll be helping you with your SOA-SHMOA efforts and will enjoy the new system as they already enjoy iPods and upcoming iPhones. SOA must improve user experience of your business clients – do not underestimate the human factor.
Yakov Fain