It is no exaggeration to say that John Crupi, chief technology officer of Sun Enterprise Web Services Global Practice, and Dan Malks, principal engineer of Sun Enterprise Web Services Global Practice, know a thing or two about service oriented architecture (SOA). After all, they wrote the book on Java software development — literally.

John Crupi

Dan Malks

Today, Crupi and Malks help leading companies architect large enterprise systems. Due to their work at the Sun Enterprise Web Services Global Practice, Crupi and Malks have become big SOA proponents. In this wide-ranging interview, they explain how to build an SOA and why pragmatic SOA really rocks.

Inner Circle (IC): It seems like everyone is talking about SOA these days. Why?

John Crupi (JC): Service oriented architecture is more than marketing buzz; it is a very valid and very architecture-centric idea. SOA is an architectural style for integration. If you look at the architectural styles in place today, they are spaghetti-like — everything is connected all over the place. And it is simply too costly to maintain that kind of architecture. The Gartner Group estimates that the cost of maintaining the integration points between systems absorbs 75 to 80 percent of all IT budgets. Implementing a service oriented architecture lowers IT deployment and maintenance costs, as well as improves productivity, because the business people are getting the tools they need to do their job. An SOA, when implemented pragmatically, enables enterprises to better leverage and integrate IT assets, while increasing the capability of business people to respond to transformation and cash in on opportunity.

Dan Malks (DM): Right. Dave Chappell talks about "accidental architectures" that were developed as separate pieces — which don't integrate — by developers who exist in their own little worlds. SOA tries to decompose these monolithic architectures into shared and reusable network-based services.

IC: That sounds a lot like Web services.

JC: SOA leverages Web services. Web services are playing out to be the technology of choice for SOA because Web services are open. But the rationale for SOA comes down to the fact that developers shouldn't be writing middleware. Developers should be writing applications. All of the middleware machinery should be generated by products. Then applications run on SOA, mostly using Web services standards and products to create shared services that transport data and process transactions.

IC: How do IT departments compose an SOA?

JC: You don't just press a button and create an SOA. SOA is about the big A. You have to architect the system. And there are obstacles that will make it difficult to move to SOA, such as the organizational changes needed to ensure success. It's a journey, but the rewards — business agility, faster time to market, end-to-end security, reduced vendor lock-in, and cost reductions — make the going worth it.

IC: Why does SOA necessitate organizational changes?

DM: Once you start looking at how to create an integrated architecture across all of the silos in today's architectures, you get into cultural issues, governance issues, and budgetary issues. Who owns a service? Whose budget does it affect? Who maintains it? There is a cultural shift that occurs with SOA, as well a technology transformation.

IC: How should IT departments approach SOA from a business perspective?

JC: IT departments need to look at software as a service. Businesses need to share data and processes as information, and in order for this to happen, IT departments must shift architecture from an application-centric model to a service-based style.

IC: How do you respond to critics who say that SOA is hard to realize?

JC: I don't think there's an option. Businesses have to move to SOA. They need to start leveraging open standards. They need to get out of the middleware business. They need to embrace an architecture that allows them to build and deploy systems more rapidly.

IC: What is the Sun pragmatic SOA approach?

JC: A lot of vendors will say: If you want an SOA, buy our product. That's not the way it works. First, you have to understand the business, and then you can architect around it. SOA requires a top-down business approach to defining what the architecture should look like. The Sun approach to SOA — pragmatic SOA — emphasizes incremental business-driven projects, a quick return on investment, and building SOA in phases. The goal is to move to SOA gradually in order to minimize risk and disruption while the IT department climbs the skill curve to SOA expertise. That is the best way for customers to benefit from the 20-plus years of experience that Sun has developed while designing and implementing scalable and extensible business systems architectures.

IC: So, pragmatic SOA is business-driven?

JC: Business units are supposed to define their requirements. That has been said for a long time, but it rarely happens. The business unit really needs to determine the architecture for services. If a business unit can't define use cases or business processes, then the IT department is going to have a problem moving toward SOA. The pragmatic approach recommends that IT decision makers figure that out before taking the next step.

IC: What do you mean when you say pragmatic SOA requires incremental change?

JC: IT departments must take baby steps toward SOA. Systems architects can't just say: Let's do an inventory of services, and these three look heavily used, so let's turn them into Web services. Again, the goal is to have the business unit drive the decision to turn a process into a service.

IC: What is another characteristic that helps define pragmatic SOA?

DM: One important idea is that SOA is more "wrap and reuse" than "rip and replace." It's a combination of building and buying, but the emphasis should be on taking existing systems and turning them into loosely coupled, business-grain services. After all, SOA is an architectural style for integration.

IC: What is the downside to the way other vendors approach SOA?

JC: We've seen customers slap a Web service interface on all of their services. That fails almost 100 percent of the time. The reason it fails is because they are trying to turn an existing piece of software into a service without addressing the architecture necessary for services.

IC: How does Sun help its customers develop a pragmatic SOA?

JC: Customers will call us and say: We're interested in SOA. We're not exactly sure how to do it, but we think there is a lot of opportunity. So, we developed a four-phase approach designed to help them analyze, identify, plan, and deliver on the promise of SOA for their particular organization. After we get them thinking about these concepts, we host a series of workshops to help them execute on those goals. First, we host an architecture workshop. We go in, sit with them, and talk about the standards. We talk about SOA for a few days, and then we go to the whiteboard and talk to them about their architecture to see where an SOA can apply, as well as what an SOA means in their context.

IC: Then what happens?

JC: Once we've done the workshop — or if a company already knows applications it wants to move to an SOA — we perform an SOA rating assessment that identifies and tries to mitigate risks by looking at where the company needs to go to create an SOA. If it's necessary to extract a business processes and nobody in the organization can do that, we identify that as a risk. If introducing loose coupling is a goal, but everything is so tightly coupled that the system may break — that is a risk. Essentially, we audit customers and show them the things they need to think about before they can develop a proof of concept.

IC: What does the proof of concept entail?

JC: Typically, we choose three to five business-significant use cases or processes that can be turned into services. But a big part of the proof of concept is helping our clients market the SOA to their management. We can't talk about agile development and reduced integration costs and then take two years to develop a proof of concept. We need to choose significant use cases, so the developers we're working with can go to their managers and say: Here are three significant use cases that we just implemented end to end in six weeks using an SOA with our existing services and our new architecture. And now that we have the architecture in place, we can add these new features in just three weeks.

IC: It sounds as if the Sun pragmatic SOA approach involves a customer-centric philosophy.

JC: We don't bring in an army of developers and live in your organization. We like to train the trainer. We help you understand your architecture, so you can do the re-architecting. We'll consult, but we don't try to take over your development.

IC: If you'll pardon the pun, the Sun SOA philosophy and the Sun corporate philosophy seem to be tightly coupled.

JC: Sun has always said the Network is the Computer. And this applies really well to SOA. We're leveraging the network to integrate network-based systems. That's what SOA is about. And Sun knows how to do that. This isn't something we just preach, either. We run our own IT on an SOA.

The Web Services group within Sun IT has a Governance Board to oversee the development and implementation of Web services across the enterprise. The Board's job is to ensure Web services are aligned across business units and can be effectively integrated into Sun's enterprise computing environment.

IC: Can you share an example of a real-world SOA project?

DM: I was the lead architect on an SOA project we just completed for the band U2. Bono is spearheading the ONE Campaign, which is attempting to end extreme poverty in Africa. You can check it out online at www.ONE.org.

IC: Where does SOA fit in?

DM: During concerts there's a call to action, and concertgoers are encouraged to text message their names to sign up for the campaign. The names are sent as a message via an inbound message service. Then, the messages are sent via an aggregation Web service to a visualization engine. The names are semantically validated and filtered through a Web service-based application we developed. The names appear on-screen at the venue, and the concertgoers cheer when their names show up. Also, the names are saved to an electronic clipboard for the ONE organization to process after the show.

IC: What has been the result of ONE Campaign so far?

DM: The goal of the ONE Campaign is to collect one million names in order to convince politicians to give more aid to Africa. They had just over 100,000 names before we launched the system in March. Since then, ONE Campaign enrollment has gone up dramatically with 1.2 million people registered. A lot of factors have played into that, including work that we did. The SMS solution that Bono uses in concert when he challenges his fans to be the generation that ends extreme poverty has handled more than 200,000 texts worldwide.

IC: Just out of curiosity, how long did it take to build and install this SOA?

DM: We had it up and running in less than a month. More importantly, it leverages the same software patterns and architectural approach that we use with our large corporate customers.