I'm the author of the InfoQ book "Enterprise SOA Adoption Strategies". Currently I am head of SOA for Global Outsourcing at Cap Gemini which broadly means I am responsible for all the projects that all the people have already built, and how you support them for the next ten years that they were meant to live.
The basic premise is that historically IT has been more not as much driving the business but leading it into a pit of despair. Most IT estates are coined with terms that are purely about the projects and systems that have already happened: the PHOENIXes, the DAVEs, the Jerold. Really IT should be about generating value for the business, that's the key thing: it needs to generate business value, and the business value ultimately is going to come from the business. When people talk about IT business alignment it really has to be about IT aligned to the business, and not business aligning to IT.
I think just from a pure structural perspective, even before we get to the technology, no IT estate looks like the business; it looks like the projects that created it - the monoliths, the silos ... IT really is a paleontology profession, rather than an architectural profession. When we are in support, which is what we do a lot in outsourcing, you can see what the company was doing in 1985, you can see what it was doing in 1990, you can see what is was doing in 1995, and it's just layer upon layer upon layer of systems on top of them. They don't look like the business, they don't behave like the business, they behave like the view of what the business wanted at that one point in time, they don't evolve, they don't move, they don't transform; so from a technological perspective in a continuous technical evolution, all of these technologies not working well together, working completely and utterly separately with fairly clunky integration.
4. So what would have to change for that problem to be addressed and how does SOA help us address that?
I think the way that SOA as a business concept rather than an IT concept helps us is the ability to understand what a business wants IT to look like. If IT alignment with the business is to happen then we really must understand what the business looks like and therefore what our IT estate must looks like. So the concept of a business service architecture is all about understanding what the business looks like, how it operates and why it does the things it does. The job of IT is then to deliver an IT estate that looks like that, rather than at the moment expecting the business to cope with the IT estate it already got.
Absolutely. I have worked with companies where the first thing we have done is change the organization structure, align the people, no technology change, no projects, no nothing, just changing the people so they are thinking about IT in a different way. They are thinking about the fact that their job is not to write a bunch of Java code to do something, it is to deliver a customer service or to deliver a sales service or whatever the services they were aligned against. So absolutely, it 100% does not have to be about IT delivery, it's about the mindset and the thinking patterns of the existing IT.
6. Can you give an example of the benefits one gains from this approach?
The first one is reduction in miscommunication. There is a traditional and it's a large cost overhead in the miscommunication between business and IT because of the two sides are not aligned. The IT side have a particular view of the world, the business side have another view and the two are not aligned. By having a business centered view and having the IT having to align directly to that, your communication patterns are much simpler and much less liable to cross issues; so that means less problems with your requirements, and less problems with your requirements means a lot less problems with your projects.
That is easy. The OASIS SOA reference model, which I was proud to be a member of, is a great place to start with the definition of SOA. It works both for the business and for the technology side; actually it is really a bridge between those two SOA worlds; it's a formal specification, it's released as an OASIS standard. I think that one of the major reasons that some of the vendors and some of the more analyst-centric people haven't really adopted it is that it commoditizes something where they love to have an opinion. It's a great commodity. To me having a formal definition of what the principles and practice of SOA are, independent of the technology, is a very powerful meme, to use the trendy word.
In the method that goes in these, that you got to understand, you obviously got to name it, you have got to say what they are, understand who you are interacting with, so what are the external actors, and you have got to understand why the actors in the services and the services themselves all interact. That is pretty much it; you can go, depending on the service you look at, you can get to the next level of formalism and then start saying: "When we do interact what the contract for that interaction, what is the motivation?" An example there is: "Why do sales report to finance when they have made a sale?" Well if they are a bonus based sale organization they are going to do that because they get a bonus. If they are not a bonus based organization they are just going to do it because are told to, and you will see different behaviors between a bonus based organization and a non-bonus based sales organization; capturing that sort of information is really important. But the level of formality isn't a massive UML diagram or a huge architectural study. Even from mapping a large business, if you are taking more than a month or so, for most organizations a couple weeks, then the odds are you're probably not getting the simplicity and you will get lost in the weeds.
I'm thinking and that's where then the key is understanding where you should be doing developments, where you shouldn't be doing developments and so if you got an existing system where it's a great big SAP thing or a mainframe, think about your support desks in terms of the business services. Do you have the same level of support for the main manufacturing ERP part as you would have for the reporting part? You probably won't, so have your support desks recognize that fact that they are different. So align your support desks to the business service architecture. If you are building a project it's much easier, new technologies of all sorts because really then you say: "Here are a series of small things I need to build, so really what I tend to say is: Stop thinking about projects and start thinking about programs of service projects. So if you got a business service architecture not all of those things are going to be built, some of them are just going to be organization elements, but the ones you are going to build, you certainly got quite a few small projects to do within a larger program; it de-risks it, it really drives in the fact that services are a key fundamental part in exactly how you are managing the project; it's not just a technology thing it's actually how you are managing the project based on those business services.
In one sense it supports it relatively well and in one sense not at all. It's the implementation technology. Could you implement a business service architecture using CICS and FTP file shifting? Actually if that's the right solution for your business then absolutely yes you can. Web services really tend to help, in terms of formalizing those contracts, so when I talked about formalizing the contracts and things like preconditions, post conditions and what security policies need to go in place, those pieces are really where some of the Web services helps because it has a way to formerly define that contract. That's business to business area where formally defining a contract is pretty normal. So taking that rigor and applying it is an extremely valuable approach. It helps to implement but it has got very little to do with the actual business architecture itself.
IF your upper management has a nice IT estate that looks like their business and they understand it in the same way they understand their business, then this would be very hard to make the case. If however you have an IT business management who really don't have IT estate that looks like their business - and that's pretty much everybody I've ever seen -, then the main selling point is "Do you want an IT estate that is evolved and managed in line with your business and critically is in line with the business value that is actually created from it." So traditional IT is very bad at that. For me that's the key pitch. You want an IT estate evolved in line with the business and in line with the business value that is created.
12. What do you mean by business value?
In the last year, we did some studies with the Economist Intelligence Unit about what is going to be the driver for IT. Right now the driver is cost reduction. What came out was that 69% of the IT was is going to be about generating business value. What it really means is how does what you're doing give a return to the business? What additional revenue are you going to be creating? What new values, new revenues? That is where SOA comes in, from a business perspective. Which services are important and which services are not important, even though technically we'd like to consider them important. (Clustering, failover etc, all of these non-functionals which are only as important as the application sits above them). If the application sits above them really isn't important, what happens if it fails? Nobody cares. Understanding that business value and the actual revenue that's going to becreated and the opportunity for revenue creation, is going to be an essential part of future applications.
There's both a challenge and a risk. How do you get people to expose a service? But also: How do you stop people focusing on "I need to create a service". It needs to be the right service. Understanding the business service architecture means you understand which services you should be exposing In terms of motivating people, part of it is what recognition do I get if I create something successful? That's where organizational structures and reviews have to come in. The way things are accounted. The simple ones that I've seen are organizations that have an "architecture tax" where they have taken 10% of all project budgets and the architecture group has been able to reinvest back into the projects that are generating services which will be reusable. Another alternative is if your project creates a service that's reusable, when it's reused by another project you get financial recognition so your project can effectively go over budget, but if it's accounted on a 12 months basis, and that service is reused, suddenly your own project is within budget, in fact potentially even could become profitable. Really aligning the KPIs of IT to producing that business service architecture people understand that that's the goal is critical. The big thing around that is stopping projects. Projects are set up to create things that fail. People need to move towards service programs because projects haven't worked in IT and they are not going to work if we're going to make this migration.
14. Do you see the same kind of problems on motivating people to consume services?
I think a great thing in IT would be if more people were lazy. That's actually how a lot of change happens, because people just use what's already there. Java is quite a good area where people have got to be quite lazy which is great; we don't write our own logging, we just use Log4J. We still like writing a new web framework for some reason every three months, but that's an example of the problem we're talking about. For consumers it's about encouraging laziness. Part of the way they do that is stop funding if people are building things which already exist in a service. If somebody says "I've got to do this", and the service exists they have no funding to build it themselves. It's equally rewarding that the project has consumed another service; so that service project has used another service and there should be some recognition reward that they are doing those pieces, those sorts of measurements should be in place. If people aren't measured based on "you will use that service" then there are a lot of people in the IT who just think "it's not good enough for me and I'll build it". They won't log the change request against the other service, they'll just build it themselves. Absolutely it has to go at the heart of the KPIs, that's why linking the business is critical because the business has the motivation to fund that success, whereas projects have a motivation to hit their deadline. If the business can say "I would take the extra one week hit because that's important to me" rather than traditional project management which looks at it in a very black-and-white world of "no, we will cut that corner because that will get me to the delivery date". Behaviors of IT have to change to really deliver a business service architecture. It's not just whacking a couple WSDLs on an existing estate, but it's all about changing the way people think and operate in IT, because at the moment IT is fundamentally broken.
Vendors don't particularly support the business vision because they're all about the service oriented delivery of IT, they are not about the service oriented architecture. They are not focusing on that business service vision, partly because it is a fairly simple thing. which therefore people won't pay a huge amount of money for; they tend to pay more for the bells and whistles. You only have to look at web services standards. I'm a bit of a fan of web services, but WS-Transaction is a great example of a vendor standard that has nothing of value for a sensible organization but is created by a certain vendor for a perceived need. That drive for that technical infrastructure without having the business context, is a major problem. It's the obsession with technology in IT that's not moving us on. It's not like the OO piece where people changed the way they thought, it's exactly like the C++ vs. Smalltalk religious wars in the 90s when everyone was arguing that that was what OO is about.
I think a big change is the rise of situation applications, participation applications, the web 2.0 pieces. The fact that the business is more and more taking these previous Excel generation of applications and wanting to run them on the existing IT estate, this currently called "shadow IT" which is a significant proportion of IT, is business aligned; it's based clearly on the business objectives, it's done by the business themselves or by surrogate IT inside the business. That to me is a big driver why this has to happen. Traditional IT has two choices: it can either move purely into a support role, and a commodity development role, or it can recognize the challenge and really start to move into what is now shadow IT. Understanding the business services and the business value created is really where web 2.0 is going to have to start delivering the value. It's not just about doing a couple of mash-ups around Google Maps; it's about how do I repurpose the existing enterprise to be better aligned to the business.
17. What's your parting message to people looking at SOA? What do you want to give them as a good hint?
Obviously, read my book! But I think the other one is, if SOA is just about the technology then all it is is lipstick on the current pig that is IT. If SOA is going to have an impact, it's got to change the way we think. SOA is about changing the way you think!