Peter Hermans spent more than two decades with the Dutch telco company KPN, and is currently active as an independent consultant and program manager in several industries. This is the first part of a two-part interview.
##CONTINUE##
The Early Days
Strukhoff: Before we jump into SOA, let’s talk a bit about your academic background and early career.
Hermans: Sure. I started in university in electrical engineering, with a specialization in telecommunications. I graduated in satellite communications for rural areas in developing countries. Then at KPN I started my career in the fixed line business, and was responsible for the development of network management systems. In the late 90s I became involved in the internet business of KPN, and when the “internet bubble” burst, I went over as IT director to KPN mobile in the Netherlands.
Strukhoff: So you’ve seen the entire telecom during this journey…
Hermans: Yes, and it was actually on the mobile side where I started to do some rationalization on IT. The mobile market growth was starting to flatten, so the focus shifted from “every month something new”—creating a lot of new and add-on IT—to customer satisfaction and a focus on costs. So I started architectural activities as a basis for rationalization and enabling more effective IT investments. Then the CIO said: “hey what you are doing in mobile, is actually what needs to happen for all of the company”.
Strukhoff: Hmm, good news I suppose.
Hermans: Well, yes, so I moved over to corporate in 2002 to develop the enterprise architecture for the whole KPN group. The core of this enterprise architecture was an enterprise service backbone—Gartner had not yet introduced the word SOA at that time—both in fixed and mobile. We envisioned at that time that there would be an end to the technology silos of fixed and mobile in the future. So we anticipated fixed mobile convergence. When it actually happened in 2007 we were ready for it. In IT we just interconnected the two ESBs, and the foundation for a converged company was there.
Stressful SOA, Spaghetti, and Lasagne
Strukhoff: The telecommunications industry must put a lot of stress on enterprise IT. Maybe even a leading-edge sort of stress?
Hermans: Yes, the stress comes from the fact that the Internet has a deep impact on the business model of an traditional telco. Up to now this industry revenue was earned by voice, “telephony minutes” as we call them. Having minutes migrate to voice-over-IP is really killing the revenues of a traditional telco. For example, with Skype I can make good telephony calls to South Africa for free! So telcos really have to reinvent themselves. This transformation process is underway on a global scale.
Strukhoff: Today, no matter really what vertical industry you're engaged in, people talk about SOA as if it's here and everybody's doing it. But, in fact, there's been quite a long evolution that I think is still going on. Could you trace for me a little bit sort of the evolution of SOA from its roots in Enterprise Application Integration and web services?
Hermans: I always look from the outside in, from the business viewpoint. The traditional way of interconnecting applications has always been point-to-point. But people start to realize that with that approach they create a lot of “spaghetti” that hinders the business in adapting quickly to their markets. So I think we should turn this spaghetti into lasagna.
There are two important elements to address here: processes and services. First we take process logic out of the applications. If today a business wants to modify a process, it has to make changes to a lot of the applications, which is costly and time-consuming. With SOA we shift our mindset from two-dimensional, point-to-point thinking to three-dimensional thinking--the process is in another layer. Secondly, we start to “think services,” not applications anymore, and organize ourselves accordingly.
Strukhoff: So how do we start cooking the lasagne?
Hermans: We started beyond traditional integration. Traditional EAI message-oriented solutions may be nice, but actually what you are doing is still creating virtual point-to-point connections. The first important and necessary step is to set up an integration competence center, overseeing it all.
Strukhoff: And then…
Hermans: The next step was to really introduce an ESB and start to decouple. Everybody talks about integration, but normally I tend to speak about “dis-integration,” because you want really to decouple and not to integrate! It is all about being “loosely coupled.” I think the use of web services will lead to an increased interoperability in the market, as the business wants to bundle and unbundle in a fast and flexible way in order to stay competitive. Through the concept of service orientation IT can accommodate that.
Strukhoff: Ah, very nice. A nice use of the word “disintegration.’ And I assume you mean decouple at the services level. But then what?
Hermans: I think that the evolution of web services will make it simpler, because in the end we will adapt to XML and all the standards that have emerged there. So making services available will be simpler and we will shift our focus to information, because that is where really the end user needs are.
Strukhoff: But not everything is standard just yet…
Hermans: You will always have to perform some functions as data mapping, orchestration, management and monitoring. And this is what I think ESBs, as the backbone of a SOA, should focus on in the future. This will be, so to speak, the “services” of an ESB which you can call for.
The Continuing Role of ESB
Strukhoff: So let’s talk a bit about ESBs and the role they play as you as you move forward to service orientation.
Hermans: It’s very important to see it from a business perspective. With web services technology getting introduced further, interoperability between companies will increase and we will see automated processes run across companies: The ESB will cross company borders and eventually industry sector borders as well; it will enable new value chains in an efficient way.
Strukhoff: This quickly leads to the questions of what business managers need to know about SOA, and what do IT managers need to know about the business when they're considering SOA?
Hermans: I see a lot of people struggling with that. So I use a lot of metaphors, and in this case I use the metaphor of a restaurant. You go to a restaurant and you want to have a nice meal. From the IT side, you can’t try to sell the cookbook to the guest in the restaurant. The business is not interested in the cookbook, the business is interested in the menu.
So my current thinking is that the nitty-gritty about how an SOA is comprised and what it all takes to build it, well, that's the trick of IT. Don't try to persuade the business with all those difficult things. Try to focus to them what it means for their business. That means that the IT people really have to think in business terms and that they have to learn to think and talk to the market as the business managers do.
Strukhoff: But yet the business managers need to be able to read the menu. How do you go about making sure they can?
Hermans: First by keeping it simple. Secondly by also teaching the business to think in terms of services. Let the business request services from IT and let IT figure out how to realize them--today with this application, tomorrow with another one, without business bothering with that. I think the concept of services has a very strong potential for improving business IT alignment.
Strukhoff: Why?
Hermans: Services is something the business understands because that is what they deliver themselves to the market. Since business has responsibility for the business processes—by the way, note that a process can also be seen as a “process”service that can be invoked—they just need to specify what service they need in each step of the process.
Strukhoff: Whose responsibility is it to tie benefits to what's being provided on the menu? Is it productive if IT can tie specific benefits in terms of TCO or in terms of increased efficiency or faster response or higher volumes? Is that helpful for IT to do that or whose responsibility is that to tie benefits to the services and architecture?
Hermans: I think it's somewhat shared. Today, the business is in the lead, the business has the budget and IT just should do what the business asks. But I think if the IT people—knowing what the capabilities of IT are—also know what the challenges and the opportunities for the business are, then they also have the responsibility to bring their knowledge on IT capabilities to the table.
I've done an assessment recently where the IT people complained, “well, the business is specifying the requirements, not only in the “what” sense but also in the “how” sense, and they came up with very specific requirements. Well, that doesn't fit in our IT so we have to rebuild our IT.”
The other side of the coin would be that IT asks the business why they need these types of requirements and with a clear understanding of that, proposing solutions that fulfill the business needs in a way that do not require a significant rebuild of IT—business and IT as equal partners around the table.
Strukhoff: Sounds like a dialog.
Hermans: Yes, because I strongly believe that success is strongly dependent not on technology but on how business and IT people work together. Also, the dialogue between all who work inside IT is equally important. Creating an ESB is 70 percent a change management and peoples issue; the technology is the easiest part. It’s crucial to pay attention to these issues since it will make the difference between failure or success!
Virtualization and Governance
Strukhoff: If we go back a little bit to where we're decoupling web services and we're flowing them through an ESB, today the topic of services virtualization is coming up. Is that something that business managers need to really get out in front of and, if so, how? Where are we with this concept of services virtualization and what do people need to know about it?
Hermans: The business should be out in front of this. Again, it comes back to thinking in terms of services rather then applications. For years, I've seen business managers formulating requirements in the sense of “I want this application to do this, this, this and that.” I said, "Stop, specify your requirements in terms of the service and then it's IT’s job to provide it."
When you virtualize your applications and expose them as services, the business might go for “SaaS” (software as a service) outside the company, and IT might start to exploit services to others outside the company. The boundaries of the company will blur. However, a lot of organizational issues need to be tackled here first. If you say the business should think in terms of services you should also have the right governance in place—for example, who owns the service.
Strukhoff: What sort of questions do business-side people need to ask about governance?
Hermans: First of all, if you have an SOA initiative, it depends on the ambition level of the initiative. Is it just a small implementation in a business unit, or is that you really start to do the first things of an enterprise-wide initiative?
If you really start on an enterprise-wide initiative then you immediately hit a number of governance issues because you are changing the whole IT structure. A business unit or business line manager will say “well, I just want to connect this application to that application. Create a point-to-point solution since that’s the cheapest and fastest way forward. And all these nice things about services and reusability, that’s fine, but I am not going to pay for that.”
As I used to say at this point, “the first passenger is not going to pay for the whole bus.” So this will require executive sponsorship, based on a vision and courage, to create a first set of services to build up to a momentum where the business starts to see the benefits of loosely coupling and (re)use of services. Within IT it requires strong business insight in defining the right services.
Strukhoff: Yet in doing so it sounds like you create more spaghetti.
Hermans: Not really. Remember that the process is not hardcoded and embedded in the application anymore, but in a different layer. You really need to talk about the BPM layer as a different layer as the one which delivers the services.
So in starting your SOA, it is important that you set up a framework. At the bottom you have your applications and data. Then you define your service layer, with your (composite) services and then your process layer. Even if you have a BPM layer in place, you might do process orchestration on top of that. I think that event-driven orchestration of processes has an enormous business potential.
Governance issues will have to be addressed at every layer. And let the business evolve your SOA implementation, no "only-IT" projects, please!
-----------------------------BY Roger Strukhoff
Source：SYS-CON
Follow the author at his blog or at www.twitter.com/strukhoff
Copyright ©1994-2008 SYS-CON Publications, Inc. All Rights Reserved. All marks are trademarks of SYS-CON Media.
Reproduction in whole or in part in any form or medium without express written permission of SYS-CON Publications, Inc. is prohibited.
Posts
0 comments:
Post a Comment