Biske: The reason that I decided to write a book on this is actually two-fold. First, in my work, both as a consultant, and now as a corporate practitioner, I'm trying to see SOA adoption be successful. The one key thing I always kept coming back to, which would influence the success of the effort the most, was governance. So, I definitely felt that this was a key part of adopting SOA, and if you don't do it right, your chances of success were greatly diminished.
The second part of it was when the publisher actually contacted me about it. I went out and looked and I was shocked to find that there weren't any books on SOA governance. For as long as the SOA trend has been going on now, you would have thought someone would have already written a book on it. I said, "Well, here's an opportunity, and given that it's not really a technology book, it's more of a technology process book, it actually might have some shelf life behind it." So I decided, why not, give a try.
The reason companies should be adopting SOA is that something has to change. There is something about the way IT is working with the rest of the business that isn't operating as efficiently and as productively as it could. And, if there is a change that has to go on, how do you manage that change and how do you make sure it happens? It's not just buying a tool, or applying some new technology. There has to be a more systematic process for how we manage that change, and to me that's all about governance.
If I just blindly say, "We're going to adopt SOA," and I tell all the masses, "Go adopt SOA," and everybody starts building services, I still haven't answered the question, "Why I am doing this, and what do I hope to achieve out of it."
If I don't make that clear, I could easily wind up with a whole bunch of services and building a whole bunch of solutions. I'll have far more moving parts, which are far more difficult to maintain. As a result, I actually go in the opposite direction from where I needed to go. If you don't clearly articulate, "This is the desired behavior. This is why we're adopting SOA," and then let all of the policy decisions start to push that forward, you really are taking a big risk. It's an unknown risk. You're not managing it appropriately if you don't have an end state in mind.
If you look at traditional IT governance, it is more about what projects we execute, how do we fund them, and structuring them appropriately, and that has a relationship to SOA governance. It doesn't go into the deep levels of decisions that are made within those projects.
If you were to try to set up a relationship, I would put IT governance, and even corporate governance, over the SOA governance aspects, at least, the technical side of it. The other piece of that is, when we talk about runtime governance, IT governance probably is focused on the runtime aspects of it. That's really a key part of this, making sure that our systems stay operational and that the operational behavior of the organization is the way we want it to be. So there is a relationship between them.
Baer: My sense is that, given the current economic environment, you're going to see a lot more in the way of tactical projects. ... We need to look at some jump-starts in a sensible, sort of "lite," like, L-I-T-E governance. That's governance that basically federates, or is compatible with, the software-delivery lifecycle. And, when we get to runtime, it's compatible with whatever governance we have at runtime.
The objective of SOA is to achieve reuse, but it's really to achieve business agility. Therefore, whether we shoot for reuse, initially or not, it will not necessarily be the ultimate measure of success for a SOA initiative. SOA Governance Lite would not emphasize very heavily the reuse angle to start off with. You may get to that at Stage 2 in your maturity cycle.
Koblielus: The flip side right now is that you can look at it as a survivor-oriented architecture. You have a survival imperative in tough times. Do you know if your company is going to be around in a year's time? The issue right now in terms of SOA is, "You want to hold on and you want to batten down the hatches. You want to be as efficient as possible. You want to consolidate what you can consolidate in terms of hardware, software, licenses, competency centers, and so forth. And, you're probably going to hold the line on investment, further applications, and so forth."
For SOA, in this survival oriented climate that we're in right now, the issue is not so much reusing what you already have, but holding on to it, so that you are well positioned for the next growth spurt for your business and for the economy, assuming that you will survive long enough. Essentially, SOA Governance Lite uses governance as a throttle, throttling down investments right now to only those that are critical to survive, so that you can throttle up those investments in the future.
Biske: I'm not a believer in the term "lite" governance. I'm of the opinion that you have governance, whether you admit it or not. An alternative view of governance is that it is a decision-rights structure. Someone is always making decision on projects.
The notion of Governance Lite is that we're saying, "Okay, keep those decisions local to the project as much as possible. Don't bubble them up to the big government up there and have all the decisions made in a more centralized fashion." But, no matter what, you always have governance on projects. Whether it's done more at the grassroots level on projects, or by some centralized organization through a more rigid process, it still comes back to having an understanding of what's the desired behavior that we are trying to achieve.
Where you run into problems is when you don't have agreement on what that desired behavior is. If you have that clearly stated, you can have an approach where the project teams are fully enabled to make those decisions on their own, because they put the emphasis on educating them on, "This is what we are trying to achieve, both from a project perspective, as well as from an enterprise perspective, and we expect you to meet both of those goals. And if you run into a problem where you are unsure on priorities, bubble that decision up, but we have given you all the power, all the information you need. So, you're empowered to make those decisions locally, and keep things executing quickly."
Another parallel we can draw to this is the current economic crisis. The risk you have in becoming too federated, and getting too many decisions made locally, is that you lose sight of the bigger picture. You can look at all of these financial institutions that got into the mortgage-backed securities and argue that their main focus was not the stability of the banking system, it was their bottom line and their stock price.
They lost sight of, "We have to keep the financial system stable." There was a risk in pushing too much down to the individual groups without keeping that higher vision and that balance between them. You can get yourself in a lot of trouble. The same thing holds true in [SOA] development.
On PE Obama's technology leader ...
Baer: Obviously, you need somebody who is going to ... think outside the box. Basically, the government has long been a series of lots of boxes or silos, where you have these various fiefdoms. Previous attempts to unify architectures at the agency levels have not always been terribly successful.
The chief priority for anybody who is ... in a CIO-type of role at the cabinet level is ... to look for getting more out of less. That's essential, because there are going to be so many competing needs for so many limited resources. We have to look for someone who can formulate strategic goals -- and I'm going to have to use the term reuse -- to reuse what is there now, and federate what is there now, and federate with as light a touch as possible.
Kobielus: it comes down to the fact that they're driving at many of the same overall objectives that also drive SOA initiatives. One initiative is to breakdown silos in terms of information sharing between the government and the citizenship, but also silos internally within the government, between the various agencies to help them better exchange information, share expertise, and so forth. In fact, if we look at their position statement called "Bring government into the 21st century," it really seems that it's part of the overall modernization push for IT and the government. They're talking really about a federated SOA governance infrastructure or a set of best practices.
Tech modernization in the government is absolutely essential. Reuse and breaking down silos between agencies is critically important. Brokering best practices across the agencies, specific silo IT and CTO organizations, is critically important. It sounds to me as if Obama will be an SOA President, although he doesn't realize it yet, if he puts in place the approach that he laid out about a year ago, considering that the IT infrastructure in the government is probably right now the least of his concerns.
Biske: [Obama] definitely has a challenge, and I am thinking from a governance perspective. He has taken step one, in that the paragraph that Jim just mentioned, of bringing government into the 21st Century. He has articulated that this is the way that he wants our systems to interact and share information with the constituents.
The next step is the policies that are going to get us there, and obviously he's time-boxed by the terms of his presidency. He's got a big challenge ahead of him, or at least the CTO that gets appointed has a huge challenge. Somehow, you have to break it down into what goals are going to be achievable in that timeframe.