We use cookies and other similar technologies (Cookies) to enhance your experience and to provide you with relevant content and ads. By using our website, you are agreeing to the use of Cookies. You can change your settings at any time. Cookie Policy.

Business Transformation in Action

Joe McKendrick

Transcript: SOA Manifesto, With IBM's Ali Arsanjani

Vote 0 Votes

The following is the full transcript of a discussion between Ali Arsanjani, distinguished engineer with IBM Global Business Services and is CTO for SOA and emerging technologies at IBM, and Jessica Ann Mola, Managing Editor of ebizQ about some key takeaways from the SOA Manifesto.

(Listen to the podcast here.)

Jessica Ann Mola: Hello, ebizQ listeners.  This is Jessica Ann Mola, Managing Editor of ebizQ.  And today I'm speaking about the SOA manifesto with Ali Arsanjani who is a distinguished engineer with IBM Global Business Services and is CTO for SOA and emerging technologies.  Thanks for joining me today Ali.  

Ali Arsanjani:  Thank you for having me here.

Jessica: Sure.  Now, first I wanted to have you give me a very brief background on the SOA Manifesto.

Ali:  Yeah, the SOA manifesto is a coming together and sort of a formal publication of a lot of things that have been going on for quite some time in the industry in terms of the values, the priorities and the principles around SOA, but at a very high level.  We've done a lot of publications, each and every one of the authors and many other people around SOA but we didn't really have something that spoke to the CEO, CXO level around the benefits, the priorities, the values and principles of SOA.  So we got together to consolidate that statement and formally publish it somewhere.

Jessica: And how did you become involved personally with it?

Ali:  We were invited by Thomas Erl to come together and do this.

Jessica:  We spoke earlier before we started recording about how you thought it would be important to clarify a lot of things with the SOA Manifesto and specifically you talked about community consensus and focusing on a middle ground.  So can you elaborate more on that?

Ali:  Absolutely.  A manifesto is usually something that occurs early on in the germinative stages of something.  So we were sort of ambivalent about publishing a manifesto now, five or six into the whole SOA stream of work.  However, when you look at it, there's no real converged published consensus around the benefits, the values, and principles of SOA.  And so, if you want to have a high-level elevator pitch discussion with the CEO, we needed some kind of a common convergent message that we could carry forward to people and that's why we decided that it's better to have it late than not to have it.  And it's a high-level statement versus a deep technical discussion.  

So generally speaking, it starts out with a set of values and the values are things you could consider them to be sort of an equation, like we talk about valuing business value over technical strategy, strategic goals over project specific goals or project specific benefits, so on and so forth.  That doesn't mean that the items on the left like the business values are absolute and that we ignore things on the right-hand side of that equation like technical strategy for example or project specific benefits.  In fact, there's always room for doing those things more tactically.  

However, if we have a choice -- if we could pick an option, it would be to opt for the left side of that equation.  Because in the long run, strategically speaking, an organization would enjoy greater benefits from addressing affects on that left side of the equation like having a defined set of shared services, defining flexibility in their systems, and conducting evolutionary refinement of their development lifecycle versus having specific purpose implementations, optimizing for very specific needs, or pursuing initial Big Bang integration or perfection at the get-go.  

Even though many of these statements may be obvious, taken together I think it's important to know that the whole is greater than the sum of the parts.  When you take all these principles or these values together, it creates a set of planning contingencies so that when you're thinking about doing shared services over specific purpose implementations, you'll try to adhere to the principles that allow you to do that.  Now obviously, they're going to be situations on projects where you can't do that.  You don't have the luxury of opting for flexibility over optimization.  You have to streamline for something to perform very fast in a short period of time and that's all right, that's the nature of the business.

However, if we did have that luxury, we would opt for introducing greater flexibility versus optimization or defining a set of shared services over specific purpose implementations.  I get a lot of questions on the service proliferation syndrome.  For example, a company comes to me and says, hey, we have thousands of services and these services are beginning to become increasingly complex and difficult to manage, each were developed for a very specific purpose implementation, they were optimized but we can't share the services, and managing, and governing then are now a problem.  

So if we have these values in front of us from the get-go as we enter into the cycle of adoption of SOA, it allows us to benefit greater and avoid some of the rework that we have to do and the backtracking that we have to do otherwise.  The values basically strike a balance between different conflicting concerns.  Those of you who are familiar with patterns know about the fact that there are forces in a patterned space, which means that they're  conflicting trade-offs to be made and those conflicts are really resolved through the application of some of the principles that we have outlined below.

For example, respecting the social and power structure of an organization, recognizing the SOA ultimately demands change at different levels within that organization.  So these acknowledgments are things that are telling us that it's not just about one project, it's not just about a specific implementation but has a broader connotation  and that the scope of SOA adoption tends to vary and you want start small and increase in terms of meaningful boundaries.  Many of these things are obvious for people who have been doing SOA and projects in general for a long time.  

However, it's important to consolidate this knowledge in one place and have it published so that if new people are coming into the SOA realm and as SOA gains more and more pervasiveness and ubiquity in terms of it not being a new cool technology anyone and its gaining more and more acceptance, people are starting to adopt more and more SOA.  And as they do so, they're going to run into the very same problems that we ran into during the five, six years that we've been doing SOA.  And so this is an attempt to set some swim lanes so people can have some general high-level guidelines in which to operate.  

Jessica:  I like that analogy, set some swim lanes.  Well, thank you very much for taking the time to talk today and for all that clarification.  I'm sure our listeners will definitely find that very interesting.

Ali:  Thank you very much.

In this blog (formerly known as "SOA in Action"), Joe McKendrick examines how BPM and related business and IT approaches can promote business transformation.

Joe McKendrick

Joe McKendrick is an author and independent analyst who tracks the impact of information technology on management and markets. View more


Subscribe in Bloglines
Subscribe in NewsGator Online
Add ebizQ's SOA in Action Blog to Newsburst from CNET News.com
Add to Google

Recently Commented On

Monthly Archives