Hi, I'm Bruce Taylor, and welcome to Voices on ITworld. Our guest today is Mike Rosen, he's a Senior Consultant with Cutter Consortium's business IT strategies and the enterprise architecture practice areas. As a former chief enterprise architect himself, he has over two decades of experience in leading the design and development of software products and applications. Besides his consulting, Mike is a frequent contributor to such publications as the Web Services Journal, EAI Journal, Software Magazine, and Enterprise Development. And he is the co-author of a book Developing E-Business Systems and Architectures, a Manager's Guide. Mike, welcome to the program.
Mike Rosen: Thanks a lot, Bruce, glad to be here.
Bruce Taylor: Well, first, we're here to talk about Web services and service-oriented architectures, so if you would, just to bring us all onto the same page, give us your clearest, most concise definition of what constitutes a service-oriented architecture.
Mike: I'll try to be concise, but I think that there are many facets to a service-oriented architecture. So when we talk about Web services, and the service-oriented architecture, mostly we're thinking about the aspects that allow us to actually connect services up to the communication's infrastructure and have one service talk to another service. And in the past decade we've had a lot of trouble with that. Previous technologies like DECOM or CORBA were just too hard to master, too complex to successfully implement service-oriented architectures. So Web services give us the opportunity for mere mortals, or most IT organizations to actually successfully implement services at a technical level. What I focus on in a lot of my enterprise clients is not creating services, but making it possible to combine those services together in the context of the larger enterprise. And that brings us an additional set of challenges and issues beyond simply Web services. So my definition of service-oriented architecture is an architecture that enables independent groups in an enterprise to separately build services that can be later combined together to form higher level value inside of an enterprise context.
Bruce: Sure, so that would imply, that as you are developing a service, that you are developing it with that in mind, that eventually it has to be tightly integrated with other services.
Mike: The idea is certainly that we want to tightly integrate the services together. But what we're trying to do with the service-oriented architecture is give the lines of business and the individual groups in an enterprise enough flexibility to actually build services that are valuable to them, that meet their time frames and business drivers. So the real challenge that we face at an enterprise level is providing just enough context so that these services can be combined together, but not so much context that we dictate to the individual groups how they have to implement things. Let me give you an example of what I mean. If we want to have services across all the different lines of business at a bank so that when a customer logs in, the customer can see their checking accounts, their savings accounts, their CDs, their credit cards, their mortgages. Then all of those different lines of business have to agree, at least at some level, what a customer is. So what we would do at an enterprise level is say an enterprise customer has these characteristics for you, my lines of business to integrate with the rest of the enterprise, you have to map your own internal definition of the customer to the enterprise wide customer, so that we communicate. So, what I do is, I give a minimum amount of context, here's what a customer has to be across all the enterprise, and then I give all of the organizations the ability to implement that context however they need to internally.
Bruce: Back in the earliest days of object oriented programming, or the earliest time that it really came to market, and back when we were trying to re-engineer business processes, there was this huge chasm between what the reality of plug and play was, and what actually happened. And my sense is that there are many IT organizations that are still battle scarred from trying to go through the eye of that needle a decade ago. What makes Web services different today?
Mike: That's really an excellent question, and I guess I think it's two things. Certainly it's absolutely true that reuse and the over hype of reuse around components and objects and services, was something that was never lived up to. In one aspect those technologies were a little bit harder to really achieve the scale of reuse that people were looking for, the reuse you can achieve at an object or a component level, is really relatively fine-grained internal implementation logic reuse. Whereas with services and Web services, what we're hoping to achieve is reuse of much larger value business services. Now, in order for someone in an organization to want to reuse something, there's a certain set of organizational barriers that they have to overcome. And when we can make the value of the service that they're using greater than the cost of overcoming those barriers, then we've at least removed one of the barriers, or impediments to service reuse. So with Web services we typically focus on a higher value service for reuse. And I think that what you saw points out the danger in Web services. Because Web services, again, make it easier at a technical level to achieve reuse. But really the issue and the reason that service reuse and component reuse failed are organizational challenges. And there's actually nothing in Web services themselves that address those organizational challenges. That's where we need a more comprehensive service-oriented architecture and an effective phased-in approach to introduce it into the organization to immediately demonstrate value and to address the, frankly, the well-founded skepticism of people who've heard it all before.
Bruce: And I want to follow up with that, if I can. I go back to when XML first arrived on the scene and I sat through some of these briefings as well, where the implied promise of XML was that -- the only analogy that I can use is like 495 going around Boston, a loop superhighway. That the reason for the loop superhighway was to avoid the urban complexity and feed services to all the suburban areas around an urban center like Boston. And I had the sense that, at a point in history, everyone was looking at what XML and like tools were going to be able to deliver was the ability to avoid the urban complexity of delivering services. Does that analogy hold true, or are we also going to be asking the internal urban complex systems of our organizations to be changed as well, in a Web services architecture?
Mike: I have to admit I've never really thought of that analogy that way before, but I think it's a very good one. What we're trying to do with Web services, or with a service-oriented architecture, again, Web services are really just the technology component of it. What we're trying to do is create a level of, or a layer of business services within the organization which really reflect the business that we're in, the business processes that we need, our value chain, our supply chain, the information that's important to the business. And that's independent of the details of how we implement it. So we can think of the business as being outside of the 495 beltway and the way that our business, our external users get to the functions is by connecting up to 495. At the 495 level, or just inside of it, what we do then is map those business services to the existing applications. So we're explicitly putting in this layer of insulation between what we need in terms of the business going forward, and what we have in terms of the complexities of the internal business today. By putting that layer of insulation in there, it allows us to change one or the other independently, without really impacting the other. So typically, we see that the business processes, the business services that are on the outside, change much quicker, much more frequently than the internal implementations on the inside and we'd like to isolate those two things. We also see that a lot of times internally we have underperforming systems, very old systems, systems on unsupported hardware, or on vendors that go out of business or something, and we need to swap those systems out, migrate them, merge them together, consolidate, whatever. By having that middle layer, it allows us to make those changes to optimize our internal business without breaking our external business services that we provide. So a very good analogy.
Bruce: Mike, in the e-mail advisor series where you wrote a two-part piece for Cutter it seemed to me that you focused, and you alluded to this a little bit earlier in the conversation, you focused primarily on the human and organizational development pieces of this, rather than the technology itself. And I think I understand that. Then you, I think it was in the first part, you had an explanation of how to develop a prototype, how to develop a pilot project, using a service-oriented architecture. And it struck me that there was nothing greatly different from what we had seen back in the business process re-design days, that this really was a pretty well-trod road. What do you see makes it different today from what we already know about how to prototype and develop successful pilots?
Mike: I guess I think that, although intellectually we've got some understanding of how to roll out pilot projects, in reality, we rarely have applied that as a way to implement a shared services model. So although we've done that for some kinds of business process things and higher level things, in reality the IT departments have been fairly ineffective at following that approach. So I don't think that it's really so much that there's anything new about what we know about how to implement pilot projects, I think it's just that maybe that we're beginning to realize much more now that really the challenge that we're facing in a service-oriented architecture is managing the organizational change, rather than the technology. And the techniques that we've used before, with some minor modifications to focus on certain explicit aspects of services, are pretty much the same. So I think you're right in that there's nothing fundamentally different here, it's just maybe the even forcefully explicit acknowledgement that to be successful, we have to stop thinking about the technology and manage the organization.
Bruce: And one of the things that I hearken to the whole agile development, project development movement, is that you seemed to be implied in your describing an SOA implementation, was that this is a time for really getting good at telling stories about what the services are that we're trying to provide. Do you see the storytelling, the creation of the visual of what a service is, as an important part of this?
Mike: What's really the critical factors of being successful with implementing an SOA and introducing it into an organization, are very different in many different organizations. So in a lot of cases, telling the story is important and it's not clear who you always need to tell the story to. Sometimes the story that you need to tell is to the CFO, and so the story has to be basically, show me the money. In other cases you are trying to convince the business users that you're going to be responsive to their needs and that the services that they get are going to provide them the quality that they need, and so there the story is a little bit different. You're trying to convince them that your shared service organization is going to act like a business that has a customer service focus. So I think that the real issue is overcoming the reluctance to adopt yet another technology bullet approach in these organizations. And having to have some real data and some compelling arguments to convince people to at least give you a chance to prove it to them. And so that's the storytelling aspect, who you're telling the story to is frequently different. Sometimes you have to tell multiple stories in the same organization.
Bruce: The other thing that you talk about in your papers that struck me, there was a message in there that I had to stop and think about. And it was the notion of picking what it is that you are going to measure to tell the story of the success of a Web service implementation. And it struck me that what wasn't being said in that, but is underneath it, is that if you don't pick the right metrics to measure what in fact has occurred within an SOA, that you miss the chance to really talk about the transformational nature of it. That when you in fact are able to link services together, have services complement each other, there is the possibility of the transformation of a service. Is that implied in what you had in mind?
Mike: Certainly the value that we're trying to achieve mid and long term in a service-oriented architecture is taking these services, combining them together, creating higher level business processes that begin to transform the way that we think about providing services to our customers. And so what we want to do is make sure that we build up a story that shows the potential for that. In reality we're not really going to probably achieve much success in combining services in transforming our organization for the first 18, at least 18 months in a service-oriented architecture program. So what we need to do is paint the potential picture and have enough reality to back it up. But this is a little bit of the sort of agile approach that you mentioned earlier. Eventually, over time, there are probably 20 or 30, or maybe that number's too big, 15 or 20 different kinds of metrics that we might want to measure around the entire lifecycle of a service. So we can't measure them all initially, the best we can do is measure three or four of them. So we want to have a good reason to pick those three or four and what I'm suggesting is that we want to choose those three or four so that they prove the value to our major customer of the SOA program.
Bruce: And when you say major customer, you mean major internal customer.
Mike: Yes, the major internal customer. Again, whether it's the CFO that we have to convince of this or the business users, or the CIO, or the CEO. Whoever, or all of them, I guess. Whoever is really the organization or power base that needs to come onboard to roll this out to the next level.
Bruce: What kind of organizations are best suited to be looking at a Web services system now, service-oriented architecture?
Mike: Well certainly ones that are information intensive. And so that would include financial services, insurance, telecommunications. Ones where, really, the processing of data and information is primarily how they operate. But even manufacturing organizations or other bricks and mortar kinds of business, have a lot of internal IT that could be optimized with a service-oriented architecture. But it seems like one of the easiest ways to demonstrate the value that an SOA brings is through a company that has a lot of customer facing presentation and collection of information. Because that's where we can start to take the services that are offered across the different lines of business and combine them together into some higher level value. And that's also some of the businesses that have really the highest competitive pressures. So where we want there to be a real business driver and to be able to demonstrate real business value from adopting this approach, something where there's a highly competitive environment around the information is something that's susceptible to service-oriented architecture. But I think that if you were building an application today from scratch, that if you were building even a single application, it would make sense to look at services as a way to implement them. But certainly if you're building more than one application, an SOA is as good of an architecture as any to build even small applications. Where the real value comes in is where we have multiple applications that we can start to tie together.
Bruce: Mike, I'd like to finish by just asking one question. If I'm sitting out there as a CIO in a small to mid size organization, and I'm looking at this. How do you recommend I start?
Mike: Great question. I think even in a small organization, a CIO is likely to find that there are few projects, maybe we call them sometimes, skunk work projects, or something, where people in their organization have already started playing with Web services. They might even discover that they've got one or two that are deployed in production. And so, a good place to start is sort of with a group in the field who really has some interest in it and align that group and their energy with some business user who has some need. So really the key here is you have to identify someone who's going to use a service, a business user that has some influence in the organization, harness the energy of this group who's already sort of learned how to do it, and then start on, really on what I like to call a continuous business value based phased introduction. So understand what business value they're going to deliver, get the customer to buy on to that, start with a limited implementation of the service-oriented architecture, make that first user happy, figure out what worked and didn't work, roll that into now a program that can start to be expanded and rolled out when you start, you don't need a lot of stuff like versioning and a service repository and a governance program and a really vigorous architecture. But as you try to get out from having 5 people build services to 500, each step you go, you need more and more detail and service and functions and value. And you need to build that up slowly over time, while you demonstrate success and continue to deliver the value to the business.
Bruce: So you would recommend still though, not developing it as if with an overarching architecture and governance, at the beginning, but start small and build slowly and build the overarching architecture based on what you've learned.
Mike: Yeah. Now, I, as an architect of course, I think architecture's important. But I also have been on many projects that I would characterize as death by architecture. And so what I think is important is that the services group has a high level service-oriented architecture vision, has a high level business process and service vision, and a high level business information vision. And they should have those three architectures, if you will, in place to help guide them in the first service implementation and help them to learn how to develop those models. And then as they evolve, they should continue to enhance those models. Overarching, to me, and to many people, implies that those should be fairly complete when you start. The rule of thumb I give is, it should take you one man-month to develop each of those architectures. One person for one month for your SOA. One person one month for your business. One person one month for your information. Any more than that you are trying to solve too big of a problem. But it is important to have that understanding and vision in place so that you're headed in the right direction.
Bruce: Mike Rosen, this has been great fun. Thank you.
Mike: Thanks a lot. Thanks for having me here.
RESOURCES
Read more about Michael Rosen
