Kerrie Holley has been an integral part of over fifty separate SOA projects in roles ranging from Designer to Chief...
By submitting your email address, you agree to receive emails regarding relevant topic offers from TechTarget and its partners. You can withdraw your consent at any time. Contact TechTarget at 275 Grove Street, Newton, MA.
Architect. He holds several SOA patents. In his current role as an IBM fellow, Holley oversees the technical direction of hundreds of SOA projects. His current focus is increasing business flexibility through the use of business rules, BPM, analytics, and of course SOA. Toward that end Holley and his compatriot, Dr. Ali Arsanjani, have written a book called "100 SOA Questions Asked and Answered."
SearchSOA.com got the chance to talk with Holley about the book and ask him some questions of our own. This is the second part of that interview. In Part One, we talked about SOA methods and identifying services. In Part Two, we discuss how agile methods and object-oriented programming fit in with SOA. In Part Three, we'll take a look at SOA and IT infrastructure and more. Stay tuned.
People talk about agile development and object-oriented programming. Should development teams keep using these methods as they adopt SOA?
Two comments there. First, often we pigeonhole methods. "We're going to use OO [object-oriented] for this, and we're going to use agile for this, and we're going to use this other method for that." I think that this one-size-fits-all with methods is not the right approach to take with problem solving. I think that we could come across a problem where we realize that we're doing three things. We're using an agile development process, we're using OO development techniques, and we're also using SOA methods. It's quite possible to use all three.
If we look at the tenets of object-oriented development, everything we write about in the book builds on those tenets. We are big proponents of object-oriented development and we recognize the benefits that it accrues. At the same time, we recognize that OO has not achieved its overall objective. That's what created the white space for methods around SOA. If we look at companies doing OO development in whatever language, we find that organizations that have built large scale enterprise applications have been successful at some things, but not at reuse –not at lowering cost of ownership –not at making those applications adaptable and changeable. And there's a multitude of reasons for that, by the way.
When we leave the concept of leveraging assets to the developer, it simply will not get done because the developer is now on the level of a clothing maker in that they're not the strategic arm of the organization, although they are still an important arm. If we want to see assets leveraged we have to leave it to the stake holders that have the visibility into the assets and ownership of them, and that's where SOA methods play a role.
OO is complementary [to SOA] and we've built upon it. Agile is a different kind of animal in that it fits certain types of problems Where organizations have to get to market really quickly, in under a year, and where organizations are highly collaborative and have a high trust environment, and can organize and work in small teams, it's really an effective organization method and SOA is definitely very complementary to that, no conflicts at all.
In the book, you state that "SOA is a journey." But agile practitioners are very used to making short sprints instead of long journeys. Have SOA and Agile been at odds in this way?
I think we'll find practitioners who think that the two are in conflict. Some may see SOA as a march – maybe even a death-march – depending on how they're implementing. I think looking at the problem that way doesn't give us the opportunity to see why people are using SOA.
For example, I worked with a company that was a big adopter of agile development. But the problems they were facing with agile came down to accelerating time to market – really down to just accelerating this one thing they're doing. However, if they're wildly successful – [they make it to market] on time and under budget – and then after production they have to go back and make changes, are they still agile? Would they still be able to go back and make changes using agile methods on what they just did? And the most likely answer is no.
That's the reason organizations are looking at SOA as a journey. It's not a matter of "boiling the ocean." We're not going to look at everything at once. But we'll ask what elements of our development lifecycle, what part of our governance, what parts of our methods, what parts of our relationship with business and IT, what parts of architecture should we adjust – not rip and replace, but adjust – in order to allow these value propositions to come to life. Not in a decade, but in months.
These are problems that SOA addresses. However, we will find organizations that are disappointed with their results, whether it's SOA or agile. We will find organizations who say they tried agile and it was "hacker heaven" that their developers were just going wild. And we will also find organizations that are highly successful; we find the same is true in SOA and in every human endeavor. The answer is not to beat up on A or B, but to understand how to make the benefits accrue.
What I mean by SOA as a journey is that we're going to constantly tweak the process. We won't be done today or tomorrow. Maybe six to eighteen months down the line we'll find a new technique or approach for transformation and we'll add that to SOA. I think as it stands, SOA adds incrementally to our body of knowledge as an IT marketplace and as a result it is a best practice and is not something you apply once. You apply it often, and that's why I call it a journey.