Tom Termini | Zen and the art of service-oriented architectures

Does a common thread run through Zen Buddhism and service-oriented architecture? Is software development more art than science? In his book “The Zen of SOA,” Tom Termini, co-founder of BlueDog — which designs SOA solutions for the public and private sectors — contends that a Zen approach can give organizations a comprehensive blueprint for modern software architectures. BlueDog has helped federal organizations such as the Justice Department and Federal Trade Commission implement SOA and Web services. We recently caught up with Termini at his office in Silver Spring, Md.

GCN: Zen and SOA — how do these two worlds connect?

Termini: For me, service-oriented architecture has been a journey.

The genesis of writing the book came out of my evolving understanding of SOA. When I sat down to try to capture my philosophy and approach as a solutions architect, it merged naturally. The idea of Zen is a life view. It doesn’t lend itself in capturing in words. If you study Zen Buddhism and spend time with people who study the way of Zen, the concepts seem hard to capture, extremely abstract. And if you dig through the various branches of Buddhism, Zen is a specific way. You have a teacher/student relationship and a more Socratic approach to teaching. And you try to absorb knowledge from that.

In the context of marrying that approach to SOA, when I started with service-oriented architecture, it seemed very rational to me. And when you look at Zen it is the same. SOA is a very rational approach to the information technology world. And it breaks down into three components — Web services, consumers of those services and a way to find those services — in the abstract, an incredibly simple model. The simplest things are often the most complicated to put into practice. So, through various undertakings — some commercial, most for federal agencies — my blueprint that I have abstractly applied has coalesced. It is not like I laid out a plan [and said] these are the lessons I learned. Some things worked, some didn’t. Some things worked in certain situations, and in others, they weren’t applicable. In a lot of ways, that is how you might approach life from a Zen perspective.

Zen comes from a Japanese origin. If you’re taking a journey through the wilderness and you see a large mountain ahead and it is kind of the way you naturally navigate, look at that mountain, it is the point I’m going to steer towards. Your overarching objective is that mountain. SOA fits that well. You got this overarching objective — you want to reconstruct your business processes so that essentially when you’re writing your Web services they’re supporting just those processes.

GCN: Do people in government really understand the concept of SOA?

Termini: There’s definitely an evolution in understanding. Part of it is the nature of federal work. Early 2003 to 2004, a lot of vendors came in doing what they normally do. They say: “These are the products we offer.” And the natural inclination for people is to say that SOA is made up of these pieces — such as an enterprise bus and a [Universal Description Discovery and Integration] registry — and these are the components of a SOA. So there was a mad rush, “We’ve got to buy all these pieces to make up a SOA.” I think these initial efforts stumbled or didn’t turn out to meet the economies that were being sought. Certainly, the [chief information officers] we’ve dealt with said they have come back to the idea of SOA. We are now in the second wave, now there is a better understanding that SOA is not a collection of commercial off-the-shelf products that you piece together.

It is moving in the direction that this is a conceptual model, and to achieve that model, there are some pieces we recognize we need enabling through Web services. We make those services available so they can be reused. Maybe the messaging layer is one way that we’re going to extend these services. In some agencies, we did projects that had a lot of interagency effort, so the messaging component became vital. In other engagements, the model was to serve the internal business customer so the message layer was less important. At the CIO level, the understanding is evolving that this is a bit higher level than a collection of pieces.

GCN: So do you think you have to start at the top, making sure that CIOs and senior management understand what you want to achieve with this concept of SOA?

Termini: The most successful projects we have been involved with, the CIO has had this overarching vision. It is part technology, but it is also part management. In these engagements where the CIO has been able to say, “I have this big goal and I understand what I want to do. Come back to me with what are some different ways to do this,” having the top-down view is vital. If you’re not up high enough, you’re not going to see that mountain.

In the past, it has been very easy for us working at the branch level to say I have a system that supports users; I want to service-enable that system. That has been one step down the path to achieve a fully rounded SOA. But it is really not ultimately the way to get there. The failure in those situations is that nobody at the top has said, “Now that we got those pieces, let’s orchestrate it into something bigger.” So that lack of orchestration is a stumbling block.

GCN: What are some other critical factors that you need for a successful implementation?

Termini: Even though it may seem like we’re talking about technology in the abstract, there does need to be a certain amount of understanding and sometimes fairly in-depth knowledge of the various pieces of technology that can go toward building SOA. We’ve worked with some CIOs who were really great managers and that was vital to getting a project done. But in the end, the projects that were declared successes were where the CIO really understood the technology components. So when we talked about this concept of orchestrating, they could understand what are the capabilities of [the various] pieces. The technical knowledge has to be there.

GCN: What do you mean by orchestrating? Is that bringing everything together?

Termini: I’m talking about this from a high level. We have one or more business customers that we are serving and one or more systems that support what they are doing. We have to figure out what are the processes that horizontally cut across those or what are the infrastructure needs that serve these sometimes competing units in an agency. So when I talk about orchestrating, that is what I’m focusing on. There are finite resources, and sometimes those are shared.

SOA requires CIOs to take a leadership role. No agency head is going to come to the CIO and say, “We need SOA.” They’re going to say, “We got a problem that we have to solve. We have to do this as quickly and cost-effectively as we can.” The CIO has to step up to the plate [and say], “I have this vision, and I'm able to marshal these resources.” The leadership has to come from taking the business objectives and interpreting how you’re going to meet these objectives with the lens that SOA provides.

GCN: In Chapter 3 of your book, you say start and end with a portal. Why?

Termini: It is the end-user that we are serving. The end-user is interacting with these systems through a browser. So ultimately that end-user experience is key, no matter what solution you are working toward. There has to be something that the end-user wants and can use. We’re talking about unifying or bringing together various services. A portal has been an instrumental tool, in terms of making all this effort on the end-users behalf really come together. That’s the front end. On the back end, you are writing services and extracting data or transforming data for consumption. It is very convenient that you know what your endpoint is going to be, a portal environment. So you start and end with the user in mind.

GCN: You have government examples in your book: the Federal Trade Commission and Justice Department. What are some of the lessons learned working with agencies?

Termini: Probably one of the recurring themes working with different agencies is to get to understand how the individual agencies undertake projects. What’s the governance process in a particular organization? I don’t think we’ve ever seen a customer that didn’t have some kind of process. The challenge is to figure out how mature is that governance process. At what point are you going to be interfacing with it. For example, is there a change control board or what’s the design and review process? Sometimes it might not be an entity; sometimes it might just be a procedural process.

The biggest lesson learned: If you stick with the SOA model, the three main components, whatever you are spending your time and effort to build, as long as [you understand] it’s a service that will be consumed by somebody and other potential consumers have to be able to find it, you’re not going to waste any effort.

GCN: Are there any agencies that you think are doing SOA right?

Termini: We did a project at the National Institutes of Health. NIH has one of the most well-formed service-oriented architectures, we’ve seen. The 22 institutions essentially all set their own agendas in IT and set their own individual goals.

Yet, somehow they’re able to leverage each others’ work in many areas because the original vision of their architecture was to put in place the pieces people would need. [IT infrastructure services] make them available and say, “Here they are. You don’t have to use them, but we’re making them available to you. If you want to use them, we are saving you effort, time and money. However, you can go off and build your own wagon.”

Or you can do some combination [where IT] provides a messaging layer. They have a really nice automated policy manager tool. To me, it was a quintessential model of SOA. They tackled a few basic services and made them available. They chose a few things that horizontally cut across all the organizations. For instance, user authentication and user management [are] generic functions that every organization is going to need. You didn’t need to use [what IT services offered] for authenticating users, but it was convenient. Because all your users are already in the user repository anyway, why reinvent the wheel?

We had some consultation with the National Heart, Lung and Blood Institute and said, “You know, this stuff is available, and you may not be aware of it in your own organization. You can go and grab it and make use of it.” We were familiar with the SOA in place.

Now, NIH is a decentralized approach. Most agencies are centralized. Certainly, the way the current [Obama] administration is focused, I think you’re going to see a lot more of that interagency resource sharing, so the decentralized model is very appropriate.