Archive for March, 2009

muSOAing for 3/31/09

March 31, 2009

In the due diligence phase, the SOA Architect has to have a very well set agenda. All the key stakeholders from the three key domains being Management, Business and IT have to be drawn. How the next phases progress will depend a lot on this key phase. The primary goals for this due diligence/discovery phase should be,

– Audit of existing IT infrastructure
– Interview key stake holders
– Good Questionnaire with relevant questions for stakeholders
– A concrete deliverable at the end of phase
– Vision Statement from each domain coalescing into an overall Vision
– Building blocks for a SOA roadmap

As mentioned earlier, a successful audit should result in a common goals strategy. It should have sufficient information that will lead to the formulation of a good SOA Roadmap. Here are some key concerns that should be addressed,

Management: ROI, Value Proposition, Operational efficiencies, Competitive Landscape, Better Services, Greater Mindshare
Business: Newer and improved functionality and Processes, Better interaction between Mgmt and IT, BPM and CEP
IT: Operational efficiency, elimination of redudancies, low maintenance, shorter learning curves

To be continued….


muSOAing for 3/30/09

March 30, 2009

What is this SOAising all about and how does one go about it. Well that is obviously a very loaded question. As I have mentioned in my earlier posts, there are several approaches that can be either Strategic or Tactical or a mix of the two which I will term Hybrid.

It is certainly not a one size fits all answer for all organizations. Here is where the questionnaire will come very handy. It certainly helps to take stock of what you have already before embarking on this journey. To use an analogy, if you are given 10 hours to build a chair, spend 5 of those hours setting up your workshop. What I am talking about here is an audit. The SOA Architect should have a well structured questionnaire. This is to break the ice. All the stakeholders have to be onboard and devote as much time as necessary to answer this questionnaire and give their free and frank views on what they want to achieve. The stakeholders should be drawn from all the key domains being Management, Business and IT.

Here is where the wearing of different hats becomes key. Talk SOA in non technical terms to Management and Business. This is not so hard as you think. It requires the wearing of your strategic cap. What does this exactly mean, I will begin to answer this starting tomorrow’s muSOAing.

muSOAing for 3/29/0

March 29, 2009

SOA projects to start with are almost never about having to write everything new and from ground up. IT organizations of any size have grown up and matured and almost always are comprised of a mishmash of systems. This is believe it or not an SOA Architect’s utopia. Another important point to note, SOA is an enterprise level effort and that should be the midset going into any SOA implementation. There is a reason why there is an “E” in ESB. BTW, an ESB is not always required for an SOA implementation. Surprised? A detailed discussion on ESBs will have to wait for their own muSOAings. The term EAI was really a misnomer. There was no Enterprise in EAI it was always a group level or at most a department level effort. The technology simply did not scale well enough to serve the whole enterprise. In these days of M&As and these massive conglomerates, SOA seems to have finally arrived as the panacea for all your integration ills er needs.

In the next muSOAing we will start the examination of this concept of SOAising your existing interfaces and how to go about building new services.

muSOAings for 3/26/09

March 26, 2009

Roadmap. This has become a favorite SOA catchphrase. Frankly speaking, SOA is one of those unique technologies that lends itself very nicely to Roadmapping. What is exactly a Roadmap. Usually when one hears this term, one usually conjures up vaporware, stuff that does not exist yet but would form the basis of the Roadmap in terms of the system that would be build over a course of time.

Well, throw all those pre-conceived notions out of the window and be prepared for some serious re-learning. With SOA, this term takes on a whole new meaning. Remember, a couple of posts ago, I had mentioned about rejigging and reusing interfaces? Well, for a very mature IT organization that has not been SOAised yet, this would form a very key component of the Roadmap.

Melding the old with the new or in geek/techie terms, “start with WSDL and Java”. Ok, went a bit overboard there, let us keep cruising at 31,000 feet. So now we shift into the next gear, so strap on your seat belts and hold on tight.

muSOAings for 3/25/09

March 26, 2009

Straddling these three worlds requires of the SOA Architect to wear different hats.   It also means that, depending on the audience, the language will have to change.     In the initial stages,  you don’t really have your foot in the door.  You have to make a strong case for SOA.    What is needed here is strategic vision,  ROI,  Roadmaps,  Business and Process efficiencies.    Not only do these have to be well qualified but to a great extent, quantified also.

Herein lie the problems.   Now how do you quantify an IT setup of system that you have not audited.   The best practices used elsewhere will play a key role here.   A lot of the existing collateral, IP and to some extent domain expertise as it relates to this vertical will play a key role.      It is never possible to arrive at exact figures.   At the same time these figures should also not be guesstimates.     The idea that should be brought across is that though the task ahead may be a complex one depending on the maturity of the existing IT infrastructure,  a well defined roadmap with all the checks and balances should alleviate all the fears and apprehensions that are generally prevalent in this layer.

So how did I arrive at the conclusions mentioned in the last few sentences of the previous paragarph.    Stay tuned for tomorrows muSOAings.

muSOAings for 3/24/09

March 24, 2009

ROI,  Operational efficiencies,  Bottom line.   While SOA is still considered a strategic  initiative,  these are some of the questions that come up when talking to the key stakeholders.   What does this mean?   The answer is obvious isn’t it, well actually it is not sorry.   The SOA Architect has to walk that fine lines between Management,  Business and IT.   These are generally worlds apart.   While these three domains play a role in any implementation,  it is more pronounced in the SOA world.

In the next few days let us examine the intricacies involved in walking these tightropes.

muSOAings for 3/19/09

March 19, 2009

So have I sold you on SOA yet?  I think I hear several loud Yeas.

SOA by itself is not hard.  What really makes it hard for people making their initial foray is this tendancy to bite off more than they can chew.    With SOA the strategy of choice is definitely divide and conquer.   Have an overall strategy for a vision but implement this strategy by taking bite size chunks for tactical advantage.  Strategic in Vision but Tactical in execution.

So what is this SOA and how do I get my arms around this.  Well,  good questions.  SOA is really about maturity levels.  How mature is your internal IT organization.    It is always not a question of if you are ready of SOA,  any organization with a reasonable IT infrastructure is ready for SOA eventough they may not know it.   Question is,  how and when do I hop onto the SOA bandwagon.

Before you embark on this exciting journey,  organizations should take the time to do what is called an SOA audit.  It can also be termed as an SOA discovery phase.  A well structured questionnaire will aid in this process.  Depending on the size of the organization and their goals and ambitions, this phase may last from anywhere from a month to a maximum of 3 months.     Please keep in mind that this phase should never go beyond 3 months.

This phase should result in some key findings key among them being,

  1. Formalization of a SOA strategy or Vision.
  2. A list of the key systems that are the revenue drivers and have a say on the bottom line
  3. The state and complexity of said systems

Remember that is is a two way street so the inputs from the SOA Architect conducting this phase are also crucial.   The goal here is to arrive at the size of the iceberg and at the end of this exercise if all you have done is seen it’s tip then you have failed in this exercise.    Some of the other key findings that should result from this are the budget that the organization is willing to allocate,  the resources in terms of staffing and infrastructure.

Once you have reasonable answers to all the questions in your questionnaire, then it is time to move into the next gear.     Stay tuned.


March 18, 2009

Recession and SOA.  The headlines you read these days are “SOA is dead”,  “SOA is a nice to have”, “SOA is discretionary spending” blah, blah, blah.   Whole lot of sensationalism dished out by armchair SOA pontificators out to grab attention.  Let me tell you one thing, SOA is very much alive and kicking and in this recession,  SOA is exactly what the doctor ordered.   Want to know why?  Well, then keep following this blog and I will post my thoughts on how SOA can help organizations in several key areas.

SOA is the McDonalds of the Integration world it is recession proof,   Period.    Here are a few reasons why,

  1. SOA lends itself to various Integration methodologies,  Big Picture top down modeling,  Ground up low level modeling  or a Hybrid approach that combines elements of the two or two seperate tracks that can merge at some meaningful meeting point.
  2. SOA standards are aplenty and have been widely accepted and implemented by technology domains hitherto considered as rivals such as the Microsoft and Java worlds.
  3. SOA is a unique concept comprising of a wide array of technologies that actually straddles the Business and Technology worlds.   It can be viewed at from a high level by non-technical business folks in terms of business processes and functions through enablers such as BPM and CEP engines and it can be low level and complex enough to satisfy that hard core technologist thru standards and myriad tools, technologies and standards  such as ESBs,  JAX-WS, Axis2,  JAXB,  SAAJ etc.
  4. SOA truly enables standards based many to many integration.   Just think about it,  all you need as a client is a WSDL.  You truly need not worry about what the backend is.  You have access to this service.  The backend can be SAP, .NET,  Mainframe but you as a client are agnostic of it.
  5. With SOA the thick line between EAI and B2B truly vanishes.   You do not need disparate technologies and standards to avail of these compartmentalized concept.   Before the advent of true SOA,  you had to have two separate strategies one each for EAI and one for B2B each supported by various heterogenous technologies and standards.
  6. Your EAI strategy might have involved the use of a one of these patterns,  Hub and Spoke,  Point to Point or Adapter based integration.  In most cases without the support of any standards such as XML or Canonicalization of your data sets.  For B2B you might have used peer to peer engines that implemented standards such as RosettaNet,  HIPAA etc.
  7. SOA easily crosses this chasm.  With SOA your integration standards remain the same, primarily driven by a WSDL/XML schema driven pattern preferably supported by Canonical schemas.    It is very easy to expose a service to the outer world and get it out of your intranet with your trading partner sharing the same WSDL and Schema specifications and the enforcement of more stringent security such as a challenge based authentication system etc.

Well I can keep going but these should suffice for now.  I will be articulating more points in my subsequent postings in a bit more detail.