Can you please tell us a little bit about yourself and what you do?

Thanks for inviting me to talk about some of the educational items we want to talk about. I'm the vice-president for SOA and Websphere strategy and channels and marketing and I've been working on SOA for the last 3 years.

What are a few things an architect needs to know to do an SOA that are new compared to the integration approaches from years ago?

I think some of the newness revolves around the interconnection of Service Oriented Architecture to the business. For instance I could do integration before without really understanding the full view of my business process. Now with SOA I not only need to understand the process but I need to be able to do a portfolio analysis and determine what I want to save in my portfolio, what I want service enable, because legacy is such an important part of the value of Service Oriented Architecture and one of the new services that I need to create. So it's really more of a building blocks apart whereas the lego I want to keep, I want to service enable and here are the new ones I need to go and build for myself to complete my portfolio. It's so much more of a direct link to the business that I think; as opposed to other projects that may have been very technology focused, SOA is very business focus. It starts a new era of business driven computing that really requires that architects truly understand the business and the business process.

What are some of the ways to get IT business alignment when doing SOA designs in practice?

So I think that to really understand SOA and SOA deployments there is 3 different sides to look at. One is to look to the technology itself (skills on the technology, enterprise service bus). That is a crucial part of an SOA. And really understanding what your requirements are and that most businesses require a mission critical view of that ESB is very important. So if you went and did a small pilot project because you didn't care about mission critical nature of scalability, you might select an ESB but when you roll it out you're going to get into trouble because you're basing your business on it right?, it's the spinal cord for your business. So looking into it and understanding the requirements for an Enterprise Service Bus. Really understanding what and how you can service enable what you have - your custom apps, your package apps today, understanding what new service you want to build and building them with reuse in mind.

And then I also think there's a set of higher level thoughts around certifications. There's there is an SOA intermediate certification and at the beginning of the third quarter we're going to introduce an SOA advanced certification. And this one is really interesting because one of the big concepts that we're on with SOA is that SOA is this alignment of business and IT; those who are most successful will understand and get that alignment in the link. It's not about doing the same thing with a different technology; it's about doing things differently. with this advanced certification you have to get through a panel review, you have to demonstrate your business acumen and your technology ability to solve a particular problem. It also prereqs the entry and the intermediate certification.

I could go on and on about the skills area because we believe if you look at SOA the two biggest inhibitors aren't technologies. The first is the cultural - the mind shift that you have to do - and the second are the skills, and making sure you have the right skills in place.

Steve Mills said that SOA is going to be on for decades not years like some previous integration EAI approaches. Why is SOA going to be so long lived?

SOA is different because it is business driven and many of the other technologies you saw the IT community pushing bottom up. But what we are finding that 60%+ of our engagements are driven top down. Why is that? Because Service Oriented Architecture starts with a service, it starts with a business task. For the most part companies are coming in with a process that they want us to help them either optimize or automate and because it starts with that business we believe that it has a lot of longevity to it. It helps truly align business and IT together. To me, that is the biggest differentiation.

Given that SOA start from the business not necessarily from the IT org how does that play out differently in different vertical industries?

SOA while having some similar characteristics by industry, also has some differences by industry. And one of the interesting ones is that each industry has a set of processes that are most attuned with the value proposition of Service Oriented Architecture. So at our Impact Conference we announced eight industry road-maps and those cross six different industries. Let me just spend a minute telling you what an industry road-map is.

So it starts out with a set of thought leaderships. What does the industry look like? What will it look like in 2020? Very valuable for an architect to understand where his/her industry is going. Then what it does, is show you how to approach that industry from a service orientation perspective: breaking it down into chunks or components of business process, business model innovation. Then it goes into best practices by each of those processes. and that's the thought leadership piece that really gets you set up around a business blue print. Architects love architectures. Think about this as a business architecture but it's a business blueprint because it's really geared at how your business works and runs. That thing gets instantiated in the technology.

So we introduced the industry frameworks as part of the road maps. And what those are a set of composite business services where actually business logic is embedded in the service itself and partner content. And all that is based on a SOA foundation that has all the capabilities that you need to run. For the first time in the industry we have 8 industry road-maps that are end-to-end for an industry around a process.Let me give you an example. In banking it focuses on payments. How do you do security and fraud? Think about it. You're an architect. If you went forward to the business and said "I want to do an SOA project", or if you went forward and said "I want to really focus on agent-client collaboration." or "I want to focus on payments and make it more secure." or "I want to focus on store from a personal shopping perspective". Those projects are probably more likely to get funded and then they are instantiated with a SOA technology underneath."

If an IT org wants to do SOA, how can they sell it to the management?

I did a session at the Impact Conference on selling SOA to your CEO or your line of business. First it's about looking at projects that are disguised projects, that are really SOA projects. Many of them are maybe compliance projects, maybe a gift registry project including improving customer's satisfaction,all those can be enabled or instantiated with SOA technology.

The other is making sure you can articulate a return on investments. Every business leader, whether an IT business leader or architect or in the business, you have to justify what you are doing. We provide a set of return on investment tools that you can use as an architect to help figure out: "This is a project I know is right architecturally; let me show you its impact on the business with the right return". By following a few sample questions really understanding it, you can calculate and take forward to your business a way to justify that particular project.

We've seen that a lot of companies start small. They say "I'm going to start with a small project and then I'm going to prove the success, and document the success factors and then take those metric forward". In my book "SOA & Web 2.0: The New Language of Business" I do a case-study on IBM and how did IBM justify an SOA project. Well their first time they went through, the CIO came through all these IT metric, and of course the business said "no". Then he came back and one of his lessons learnt was that "I wasn't speaking business to them, I was speaking IT". He came back and said: "When we get a new supplier and they want to link in our supply chain, instead of having them take 3 weeks I can do it in an hour". That meeting with that one statement, he was funded and ready to go, because he changed the way he was justifying the project, and he spoke a different language. There are a lot of lessons learned like that in the book, so that you can learn how to communicate the real value and power of SOA.

What are some of the key takeaways from the book?

I think one of the biggest takeaways to me is that it's not just about the technology as it is about a new way of thinking about the business. It's about thinking of my service orientation of my business that is based on architecture and service orientation requires that companies, in particular IT, really get this mind shift. An example would be the creation of a service. You create a service but do you know all the customers are going to use that service so that you can communicate when you make a change to the service? Do you understand or monitor so you can make improvements and advancements on it versus "I've created a service and I'm reusing it." It's really changing the way you think. It's changing your reward structure. Many customers that we talk to today, reward on creation of new code. IBM did that. We gave awards based on patents.

SOA is all about reuse. Reusing and composing: and so changing reward structures to reward those people who create reusable services and those people who use them. It is about a mind shift and how you're approaching your business, how you're making your business more agile and more flexible in the market place. More than just technology.

Are BPM and SOA two sides of the same coin or is one a prerequisite of the other, or they are really parallel concepts?

I think that BPM and SOA are two sides of the same coin. I don't think you can do BPM without leveraging SOA. Infact, Gartner, you can't even get to the higher levels of BPM (the maturity) without SOA. If you think about Service Oriented Architecture without a focus on process you can't be successful on SOA. The two are melded together and they allow or enable each other to accomplish their goal.

For us business process management (BPM) is a set of capabilities that are embodied in technology (software). Along with methodology an approach to the process, an approach to understanding what your process looks like, an approach to understanding how to really go through and determine bottlenecks and inefficiencies and how to project what happened if you changed that process. 80% of process changes fail because companies fail to realize the implication of that change on their business. Leveraging a methodology can help you determine what changes to make and then a software tool to help you predict the impact on the business is the combination. A lot of people talk about just the software or just the methodology. We believe that BPM requires both of those and of course the software being built with SOA principles in mind.

Initially IBM's view on ESB is that it was something virtual, like the sum of all components that give you what should be an ESB.. Now there seem to be 2 ESB products; one based on WebsphereMQ one based on Process server. Which one is the true ESB?

IBM started talking about patterns of ESB. What we saw as early adopters of SOA in the marketplace they were saying this: "for my strategy I want to do it this way or this way". As we moved past that early adopter stage and now to early majority we found and detected a set of patterns that we instantiated in the products. Websphere ESB is one and it bases on people who are all based on web services standard. We have Websphere Message Broker which we consider our advanced ESB. If you have a heterogeneous you mix with webservices standards and other standards that you leverage in your environment. Most people, for an ESB, are leveraging for mission critical SOA that Websphere Message Broker.

Recently we have acquired a company called Data Power. Data Power is an appliance which is a hybrid - software and hardware you can't decouple the two. It's a box that you just plug in. that is now our third ESB and we announced at Impact Conference, it's a data power box called XI 50. It has built into the box ESB connectivity capability, messaging capability that you'd find in a certain scenario when you'd use that particular ESB.

Right now we have three ESB products based on the three patterns that we found from those early adaptors that makes it easier for customers to deploy a mission critical Enterprise Service Bus.

Where does process server fit in?

Process Server has server ESB inside of it, it is embedded inside of it. We have many customers who say that the embedded ESB there is only for web services. Many of our customers will leverage process server with message broker or process server with our data power appliance. There's no reason why you couldn't have multiple ESBs for different purposes.

In your book you profile a lot of companies that are doing SOA right now. What does it typically look like? What is a successful Service Oriented Enterprise?

In my book, one of the things that we did was as IBM we introduced a set of entry points. There were 5 of them: the people entry point, process entry point and information. Those were more business centric more driven from the business side of the organization. Then there were two IT focus entry points around re-use and connectivity or that ESB. What we found is that when looking at the time (we had 3600 customers, now we have 4500 customers) we found that those were the five patterns; the five ways that they start their SOA deployment.

One of the first critical success factors we found was that a company starts with one of those and then later blends in the other entry points. Let's look at some examples. We can look at Harley Davidson who is a manufacturer or retailer in the US; they sell motorcycles and clothes, great company. Jim Haney- the CIO - was looking at his processes and the process entry point, his financial process linked to his marketing process. He leveraged SOA, more particular the Websphere Process Server, to decouple those processes, turn them into services that could be flexibly and agily changed as needed based on the market. He started from one but now he is leveraging information as a service to gain more insight about his customers.

Another great example is Burling County Schools. Their school system is very innovative; they wanted to have a portal to help them with the "no child left behind" role, where they have to produce reports and stats about test results of their children. This was taking them a lot of time, it was a very unanimated process so they decided to use a portlet and get views from over 4,000 applications displayed in the portlet so it would be easier to get the test results. They could have done that without SOA but they wanted to make those reusable portlets into other applications or composites later. So they chose SOA to improve people productivity, set up the portlet to help with the "no child left behind" line but the result was that those reusable services and components were then constructed into role-based systems to assists teachers with giving out assignments. They have a lot of students who speak many languages, so now they can translate homework so if a parent spoke Spanish, Russian, Chinese etc they can get the homework assignment in their language. That's the people entry point.

But of course you can't touch people productivity without touching the process. The same thing is true on the underlying technology. A lot of customers start with making sure they have the right foundational infrastructure. "Do I have a mission critical ESB?" St. George's Bay (Australia) did this and made sure that they had a strong basis because that is what will rat all your services and connect all your services together.

Or a focus on reuse: "How do I reuse the capabilities that I have within?". At the Impact Conference Wachovia spoke - the third largest bank in the world, the third largest brokerage in the world, number one customer sat bank for six year running, and they leveraged a lot of reuse of their system Z applications in their environment to be successful.

IBM is a great case-study, it's a number one downloaded case study off of our website. In my book there's a whole chapter on my interview with the CIO and the three different projects that he did and the lessons that he learned each time. Through the book he shares some of his insight of what he would do differently, starting over and what he has done differently as he progressed in his maturity.

Any final words to technical architects about SOA?

My message to technical architects is that your role is so important. This is about Service Oriented Architecture so it is about getting that architecture right, that underpinning IT blueprint right. But your role is so much more important with SOA that it has been in the past. You're now asked to really understand business process, business models on an end to end basis, and really apply the technology or infuse that technology into your business. I think you as leaders in your organizations (most organizations I know the architects as leaders in the organization) my message would be that in order to be very successful with SOA, start that mind shift, the way of thinking, towards service orientation thinking about your business as a set of services and what do I need to do to make that successful in the business will make you be much more successfully both personally on a personal side as well as on a business side and technical side. At the Impact Conference we reviewed key points on each of those: the business impact of SOA, the technical impact of SOA, and probably most important to most people is the personal impact of SOA.

You mentioned that you see SOA as being the early majority stage. What does IBM see in terms of SOA adoption and what is still left for the industry?

In the last three years I've seen SOA grow from an early adoptor phase to early majority. If you've read "Crossing the Chasm" you‘ll know where that fits on the scale. If I look at businesses, ten of the top 10 telecommunication companies are leveraging SOA and IBM to transform their businesses; if I look at 10 of the top 10 banks, if I look at health plans in the US. 80% of the US health plans are leveraging SOA in their environments. Regardless of the industry 3 out of 5 retailers are leveraging SOA. Regardless of where I look I see that the leading edge companies are adopting, piloting and in some cases are in production with SOA today. I see it now moving from early adaptor to early majority. Companies are recognizing that this is a competitive differentiation we alone have 4500 companies that are using our SOA offerings. That is a lot of companies who are leveraging and trying the technology. From three years ago to now that's a tremendous gain of momentum. At the Impact conference it was the world largest SOA conference and we had over 4200 attendees. We'll have as many attendees in second life , next week we'll go to Paris , then Spain, Madrid and then to China. This is topic that is compelling that people are using and leveraging. I say it has matured and its lifecycle is there but those leading edge companies are using it already. Even the Gartner reports will tell you by the end of the year that 80% of companies will be leveraging Service Oriented Architectures somewhere in their environment. So if you're thinking about it now it's the right time. I talked to NY tax and finance and the CIO was saying that he went to a SOA conference in March last year and he realized at that conference , by looking at the number of customer references and customers telling their story that he had to take action then. He did and now he is a great customer reference for us of the benefits of service oriented architecture.