SOA foundation, Part 1: Business-driven development Patrick Flanders interviews Rick Weaver and Rawn Shah 02 Dec 2005 WebSphere Technical Podcast series on developerWorks http://www.ibm.com/developerworks/podcast/websphere/ Patrick: Hi and welcome to the sixth installment of the IBM WebSphere Technical Podcast series on developerWorks. This series features interviews with IBM technical experts to help you better understand important software development issues. I'm Patrick Flanders. I'm an editor with IBM developerWorks and your host for this series. Up until now, we've talked about some principles and techniques for developing services-oriented architecture applications with WebSphere technologies. We'll shift gears a little in the remaining three podcasts of the year and talk about the IBM SOA Foundation. This is a set of principles on which SOA is based. Today, we'll talk about business-driven development, which helps organizations, and especially the IT architect, to align business goals and processes with solutions implemented by IT. Who else to help us understand an architectural subject than an IBM architect. And joining me today is Rick Weaver. Rick is the Portfolio Manager for the IBM WebSphere family of development tools. And since he also helps drive development tool strategy within IBM, he's a great person to help us understand the ins and outs of the IBM SOA Foundation. We're also joined by Rawn Shah. Rawn is the community editor for developerWorks and is a long-time contributor to the Web site. He was the editor of the SOA and Web services zone until last year, and just recently published the developerWorks series book "SOA Compass: Business Value Planning and Enterprise Roadmap." Thanks for joining us gentlemen. Welcome to both of you. Rick: Thanks so much, glad to be here. Rawn: Hi Pat. Patrick: Well, let's start off at the beginning here. Business-driven development. Tell us a little bit about its heritage. Where does it come from, and what problems does it address? Rawn: Well Pat, with products becoming more commoditized in the industry more frequently, businesses are trying to differentiate themselves from their competitors by attaching services around their products -- that they're more often turning into service providers rather than just purely sell as a product. To stay competitive and gain business agility, companies now need to look towards improving the services and the delivery of these services. Since this also includes the product development and the technical development and infrastructure of the company. Now, what they're moving towards is something in between and this is what has led to the service-oriented architecture. Here there's a common view of development and operations from both the technical and business side, and it's both a service and process-based system into an overall architecture. Rick: So when I think of business-driven development, and I'm asked this all the time, you know: "Rick, what is a one-sentence description of what business-driven development is about?" And it's simply to accurately and reliably capture and translate business intent into IT solutions. And if we kind of decompose that statement a bit, you know, one aspect to that is to be able to align business goals, business requirements, business use cases with what we're doing within IT. And that's certainly one important aspect. The aspect I'm going to focus on quite a bit today is: How do we actually align and optimize business processes and using these business processes? How do we actually efficiently drive what IT actually produces? And that is really what business-driven development is all about. Patrick: That's a great overview. Now, we've heard that a fundamental aspect of business-driven development is business-process modeling and optimization. Rick, can you explain what that entails -- and specifically how the architect undertakes those tasks? Rick: Certainly. So as we step back and look at business-driven development, there are actually four key roles I want to focus on for a moment. The four roles are how the business analyst, the architect, which you mentioned, the developer, and the integration developer and how they work together. So if we look at the first role very briefly, the business analyst is focused on how we model the business process -- how they actually optimize it through running what we call simulations. An optimization may mean many different things to a business. It may be: How do we reduce cost or improve revenue? How do we reduce time? Many different types of business drivers might influence how we actually come up with and optimize business-process models. So as the business analyst comes through, models and optimizes that business-process model, many times we refer to that as a "to-be" business-process. Now once the business analyst has done the work, this is where the architect becomes a critical member of our development team for business-driven development. Because the architect now needs to analyze that business-process model and they need to do it in a format that most architects are comfortable with and that's typically UML. And the role of the architect is now to understand what the business-process model was from the business analyst and start identifying services that we can potentially reuse for this business process. Or perhaps what we need to do is to start doing some new development and doing some new service modeling and perhaps we use things like patterns to help us actually do that, that take these IT-level services and map them back to this business-level process model. Now the third role is that of the developer, and the developer is focused on how do we actually implement services that the architect has actually modeled. And then finally the fourth role, this is an integration developer, focuses on how we actually stitch together the business process and actually build something that deploys into a runtime. So as we can see, the architect plays a pivotal role in understanding what is the business intent, and being able to map this into IT-level services that we actually emit. So, the role of an architect is important, but as you can see, business-driven development is a team sport. Patrick: Rawn, do you want to add to that? Rawn: Yeah, and actually Rick said it perfectly. What we're thinking of here is: Has the ownership and the responsibilities of the different activities in this project being planned out, has it been divided appropriately? Have you identified who from your existing team should be involved? Have you talked to your executives about getting support for this project as it's going along? On the technical side, has the development team considered moving from just purely a programming mindset to something more along a process-driven mindset? So these are the kind of questions that you'll probably ask when you're thinking about building an SOA. Patrick: Now, another part of business-driven development that might not be as well known is service-level definition. Rawn, what does that mean, and how do you put that into use? Rawn: Well once you've identified what your services will do -- what you get from that service, what role in plays in the overall process - - you're essentially moving towards defining the characteristics of how that service will perform when it executes. Service-level agreements make use of these definitions. You can think of service- level agreements simply as the business and the operational rules of running one or more services as part of the process. And then there's a process-level definition as well. Patrick: Now Rick, I'm going to direct the next couple questions at you, since you're the expert on these things. And Rawn, we'll come back to you here towards the end. So you've defined what essentially amounts to business processes and requirements. So what's next? How do you transform that into a technical model for the services you need to build? Rick: Really the first step as we start trying to bridge from the business-process model world to a technical model that we actually implement in IT is for this architect to be able to visualize and understand what is that business model? And so we can use tools such as Rational Software Architect where we can actually open that business-process model and visualize it in UML. This really helps this architect gain that understanding to what that business-process model is. And the great thing about that is nothing gets lost in translation between the business analyst world on the business side and what we're doing on the IT side. Now the architect can start designing that technical model and define the traceability from this technical model back into the business model. Now there are a couple of approaches for us to actually accomplish this, and we'll find both approaches are actually quite complementary and we use them oftentimes in parallel here. So one approach is that we can apply a UML profile for software services within Rational Software Architect and this allows us to do service-oriented modeling. So by using this profile, we can model the services, we can model the messages used by services, and then model the compositional view of how these services work together, are related together. That's absolutely important. And that starts getting us to flesh out: What is the technical model? Now another approach, which is certainly complementary as I mentioned, is using patterns. As we think about the value of patterns, patterns are useful for us to establish best practices principles for us to improve the efficiency and quality of the services we model. And so as we start building our repositories with patterns that we can apply, we can use this as a mechanism for generating and driving our service implementation. Finally, of course, traceability is important between the technical model and this business model. And so the architect, as they start defining the service-oriented modeling, they can go through and define the traceability so we can see the relationships from the business process model and the business-level services into the IT view as well. Patrick: Tell us where process choreography fits into this. How does that method help you turn business process models into an executable technical model? Rick: Well, when we hear the words process choreography one of the first words that comes into mind is BPEL. And IBM specifically has tools such as WebSphere Integration Developer which allows us to choreograph those services together to build a deployable business process. This BPEL-based business process we would deploy into a runtime such as the WebSphere Process Server. And the great thing about it is that, you know, the origination of the business process model came from the business analyst. The typical tool that a business analyst would use would be a tool like the WebSphere Business Modeler and that has capabilities of basically exporting BPEL that we would bring into the process choreography tooling that we'd go back and stitch together these IT-level services, build a BPEL process that we would actually go through and deploy into the runtime. Patrick: Rick, you've discussed BPEL and we know that this approach is obviously standards based. What standards the architect and the development teams need to support for business-driven development in their SOA development efforts? Rick: Well, there's two ways to look at standards. I tend to look at standards and talk about infrastructure standards and semantic standards. So by infrastructure standards, these really are the standards that help us with interoperability, portability and all those "-ability" words. So we can talk about things like HTTP, we can talk about XML, XML Schema, we can talk about service description and WSDL, talk about interoperability and profiles like WS-I or the protocol-enveloping mechanisms of SOAP, talk about UDDI, RAS and of course BPEL for service orchestration. Those are all absolutely critical, and it's a part of business-driven development. But where we see the true buy back of business-driven development and SOA is at the semantic standards level. Let's say, for example, that I'm in travel and transportation and if I can define semantic standards for booking a flight, doing a low-fare search and that becomes a semantic standard in my company across the industry that I'm in, then we see a tremendous buy back in the benefits of SOA and the benefits of business-driven development and we can establish these semantic standards. Yes these semantic standards are based on these infrastructure standards that we talked about earlier, but this is really the objective of business-driven development is to achieve the semantic standards that are used throughout my company and, of course, ideally throughout the industry. Patrick: So we're getting pretty close to the end here, so let me ask you this: Any parting words about business-driven development, you know, what are the main things that you hope our listeners would take away from this and where would you suggest they go for more information? Rick: Sure, so as we think about business-driven development, the one thing that I always emphasize is that there are many on ramps to business-driven development. You know, being able to take and visualize business process models and running simulations has some intrinsic value in of itself. As I think about being able to take a process model and visualize it in UML and I go no further than that. There's some intrinsic value in that as well. So many different on ramps, you know, I work with a lot of customers that perhaps do a lot of modeling in UML so that can be a logical entry point into business-driven development. And these incremental steps as we start adapting this is critical for us to achieve success. The other thing is that requirements management is absolutely critical as well. How do we trace requirements from business-level use cases to process models to system use cases? All that kind of good stuff. So requirements management -- injecting, you know, RequisitePro into those type of solutions -- is critical for use to achieve the traceability from the business side to the IT side. I know we've covered a lot of topics, so my recommendation is that if you go out and Google on the IBM SOA Survival Guide. You'll be taken to a spot where you can get a lot of more information on business- driven development and a lot of the topics we've talked about today. Rawn: Yeah, and I'd like to add that we've put together a lot of the knowledge we have from the IBM integration teams about service- oriented architecture and the many different projects they worked on into this book, the "Service-Oriented Architecture Compass." This book is out on shelves right now. You can take a look at it, or find more information on www.ibm.com/ibmpress. Patrick: Well that's great stuff, Rick and Rawn. I really appreciate your time and on behalf of all of our listeners I just want to thank you for joining us. Rick: This was fun, so thank you. Rawn: Great talking to Rick and it's great talking to you Pat. Patrick: Great. Well thanks guys. We'll continue to talk about the SOA Foundation next time, when we dive into the SOA operating environment, so come back if you're interested in learning more. Thanks our audience for listening in from wherever you are. To find out more about WebSphere or IBM technology in general, I invite you to check out developerWorks on the ibm.com Web site. Just point your browser to www.ibm.com/developerworks. Again, that's ibm.com/developerworks. There you'll find thousands of original articles and tutorials, as well as discussion forums, blogs, and other interactive tools about open standards technologies and IBM development products and tools. For more information and resources related to this WebSphere Technical Podcast series, and those topics specifically discussed during the podcast, please visit ibm.com/developerworks/podcast. And again that's ibm.com/developerworks/podcast. This is Patrick Flanders for the WebSphere Technical Podcast series on developerWorks, and remember, we're more technical than music. Thanks for listening.