Year in Review
What’s happened this year is that SOA has become mainstream, if one can say that, in the IT industry. Maybe it hasn’t in enterprise companies, but it certainly is in the IT industry. A lot of companies have acquired a smaller or larger companies in order to build their portfolio.
We’ve had a bevy of consolidation events, mergers, and acquisitions. We’ve seen some large vendors further and more deeply embrace SOA. We’ve seen startups realign themselves around the SOA message and value, and we’ve seen SOA extend, perhaps a little bit high in the stack, around application and services, and the application-as-services in more than the infrastructure.
The one thing that’s been lacking so far -- and I’ve talked to a number of vendors about this -- is integration, which is to me the ultimate irony, because its exactly what SOA is about as a concept. It’s about helping bring together the disparate pieces.
One of the things I’ve talked to a few vendors about is the fact that they’re actually having to become service-oriented in terms of how they put together their products, deliver solutions to their own customers, and how they build more specific suites of capability that suits the needs of specific customers. We’re at the beginning of something that is all about how we move away from just having a consolidated set of resources. The point about Red Hat JBoss was well made. Everyone needs all the pieces, and now it’s a case of how they compete in terms of how they deliver the integrated solutions to the market.
Vendors who naturally don’t have all the pieces will try to acquire other companies that do -- to will fill in the blanks, so to speak. That’s really what’s going on here.
It was very important from a competitive standpoint for those two companies to get together, so that they could respond in a way where they could say, “We’ve got a comprehensive answer to the SOA problem that other vendors have.” The impact from that perspective was mostly in terms of the two vendors getting together and being able to compete effectively.
SOA, certainly from my experience, came out of the developer world, in terms of evolving out of component-based development and out of the Web-service based application space. It’s really a post-deployment characteristic of enterprise architecture, and if that’s the case, then it needs to built in. There’s operational management. There’s deployment management. How do we cope with this stuff once we’ve got it? The idea of a registry, the idea of a repository of assets, all of these things start to kick in.
It’s broadened out from it’s original space and it’s gone into a place where governance is much more necessary, but equally it’s a symptom of maturity. A lot of IT starts in terms of innovation, where people are pretty much left to work out how. Networking started with people saying, “Hey look, we can join this to this,” and then suddenly everyone’s joining everything to everything. After that, people are saying, “Shouldn’t we start to work out whether or not we should be joining things together?” And there’s a level of maturity that I think we’re hitting with SOA, which means that governance becomes far more important.
Governance is a loaded term for obvious reasons, but if you look at the whole notion of SOA, it’s supposed to make exposing your assets, and your data enterprise process assets, easier. If you think about, that kind of goes against the objectives of a lot of the regulations of enterprises.
As we open these assets up, we expose them as services. As we start to ramp up beyond pilot stage, we need control and we need to document what assets are being exposed to services, under what circumstances, to whom, and when. We have to start getting into versioning issues. What’s interesting is that until now SOA has been primarily a skunkworks operation, with few exceptions, maybe for someone like the Verizons of the world.
Mostly we’re focused on runtime governance, which is what services can we expose to which requester at run time, but that was largely in a fairly controlled environment. You’re starting to see more attention to the rest of the lifecycle.
ESBs were at least one of the top stories in 2006 in relation to SOA. That makes sense, because as people started to adopt a SOA approach, whatever that meant to them, they were searching around for the right infrastructure elements that they needed, in order to make that architecture work for them.
Some of the confusion around ESBs has stemmed from the fact that they’re pretty big items in terms of what they’re capable of doing. The reality is that a lot of organizations may not need a full ESB, as many vendors are defining it, to make their environments work. They may already have some of the integration capabilities. They may have some of the event-handling capabilities in place, and they really may just need some mediation and governance elements added in, in order to make their environments work. That’s introduced a bit of confusion that has caused some grief amongst end users, at least the ones that I talked to.
There’s a tendency also to look in the other direction in terms of sort of creating an “Uber ESB,” if you will, one instantiation of that being in the form of a JBI implementation that will allow people, regardless of how they’ve chosen to implement the functionality, to bring that all together and integrate that into a complete environment. What you then get into is, “How do I navigate the world of standards to make sure that I’m adopting this and implementing it in the right way.”
So, ESBs have been very prominent. There’s been a lot of noise, news, and discussion about ESBs, a lot of product announcements in 2006. I think you’re going to see that continue in 2007, hopefully in a way that clarifies and brings together the activities to something that’s coherent and therefore makes organizations feel comfortable that they can move forward.
What’s very interesting is that in the past year IBM finally admitted that ESBs are not just an architectural pattern, it’s actually the real product. There’s been a lot of confusion, fear, uncertainty, and doubt out there as to what ESBs actually are. What I would love to see -- and of course this would probably never happen -- is some industry consensus, “Here’s a Lego blocks model. Here are different things that an ESB can do.”
To Microsoft the ESB probably meant enterprise service buses or those vehicles that employees ride around on at the Redmond campus. It seems that Microsoft has gotten on board with the ESB concept lately as well, which surprised a lot of observers, because Microsoft usually likes to take its own route with things and not buy into the acronym of the moment.
What's in Store for 2007
I’m also going to go out on a limb and say that I’m going to expect some more big SOA-related acquisitions again in 2007, and I’m going to look to SAP and Oracle as likely candidates for acquiring other companies. The net-net on that is the application guys are going to start to flex their muscles on SOA. If you have both the infrastructure and the applications, and then you produce the SOA benefits, that’s a very advantageous place to be.
Maybe in 2007 we’re going to be hearing more about EDA, Event Driven Architecture. It has more of an action sound to it. It’s something new, and it has that real-time aspect that ties into business intelligence, and can be integrated well within business intelligence solutions.
So, I wouldn’t be surprised if we saw vendors moving away from SOA terminology and toward things such as EDA, maybe software as a service. Maybe we’ll be hearing more about that. At the enterprise level, the end users in the trenches, where the real work takes place, there’s going to be slow, steady progress toward the SOA model. It’s not going to be a revolutionary thing happening in 2007. It’s going to be evolutionary.
I think we can also look to 2007 as being the year of modeling. I think we’re going to see a lot more product and specification and methodology around the modeling of services that can leverage and exploit some of the activity from 2006 around this governance and the registry and repository. I’m expecting some much improved tools, graphical tools, and some innovative approaches to how to choreograph -- and that plays into your event-driven stuff, too.So 2007 will be the beginnings of what you’re terming as a SOA build-out, but I’d like to deal with less of a product- or a vendor-related issue now and talk a little bit more about end-user organizations themselves. I’m still amazed, somewhat amazed at how much I’m hearing organizations talk about two issues.
One is that we hear about IT, business analysts, and business people working together to come up with requirements and actually having tools where they can work together to build business processes and then implement them and support them with services. But, little of that is actually going on and being effective within organizations. I hear a lot of folks on both sides of that pointing fingers and claming that the other one doesn’t get it, and that’s sort of manifesting itself in several ways.
It’s partially responsible for the pilot-nature of implementations that you see today in most of our organization that have tried SOA. I think it’s also responsible for the overall slowness with which you see this moving through some organizations. Over 2007, I think you’re going to see some shake-out and some advancement in terms of building that bridge between the two organizations within corporations that want to do SOA and therefore forming the foundation for moving on, but I don’t quite think we’re there yet.
There are two elements to that. Organizations that have not done it yet are going to, for the most part, remain down at the 3 or 4 level, if 3 or 4 level is defined as doing small-pilot implementations. Some percentage, say 25 percent to 30 percent of those organizations that have gotten to that first stage, will move on in a big way. I still believe that there are some impediments, having in some part to do with organizational issues and the relationships between IT and business, that are going hold that up a bit.
I’m also predicting that this notion that Web 3.0, which is better characterized as the "Semantic Web," will offer on one hand competition against the SOA messaging and value, but more importantly offer a tag-team approach. We’ve discussed this a little bit before around Web 2.0 and Enterprise 2.0.
If we do start getting some specifications, and as IP Version 6 becomes more widely deployed around the world, we’ll get much richer in approaching this level of a semantic Web capability on the network. If you can combine that with what you’re doing internally, that that’s one of the big tipping points for the further adoption of SOA.