What is your e-mail address?

My e-mail address is:

Do you have a password?

Forgot your password? Click here
close

SPECIAL REPORT: Service Oriented Architecture

Establishing Common Ground
The goal of the Practical Guide to Federal Service-Oriented Architecture is to provide government with a road map to implementing SOA.
*Architecture: A 12 Letter Word For Having A Plan
*Establishing Common Ground
*SOA: Health Care Enabler
*SOA: Evolving Challenges
*Governing Principles
*SOA Improves Services [Online bonus material]
*SOA: Service-Oriented Architecture [PDF]
Systems should be designed, developed and integrated so that in essence they act as if they are one single information system. That’s a major objective of SOA – the sharing and reuse of services rather than building unique systems. There is no reason one system should not be able to link to another system through a service to share information.
 

“The Practical Guide for Federal Services Oriented Architecture (PGFSOA) came out of a realization that SOA vocabulary, approaches, technologies, techniques are getting more mature,” said Kshemendra Paul’s Chief Architect at OMB.

 

“But there are a lot of different approaches; there’s a lot of hype in the marketplace and a lot of things that are unique and not unique about the federal government,” explained Paul. “We felt that it would be a useful service to the IT community across the federal space to try to put out a common vocabulary for how to think about SOA in the federal space; a reference that established a body of knowledge that represents best practices that are out there, whether they are in the academic community or the technical standards community.”  The PGFSOA has been developed to meet the unique challenges the federal IT community has to address. “One thing that is unique about the federal government is the degree of mandates that we have to work through in the security space, the architecture space and so on,” noted Paul.

 

Paul also noted that the government built vertical IT stovepipes in the past built to meet program needs perceived to be unique.  “A lot of our challenges are more horizontal, where we have to go across organizational boundaries, so how do we make that work?” asks Paul.Those kinds of issues, which often come under the heading of governance, are really what make SOA in the federal space different. “So we wanted the PGFSOA to tell the story in the way the chief architects around the federal government communicate to their program executives in their departments and their CIOs and other stakeholders in the process.”

 

Six Tenets

 Paul said the PGFSOA focuses on six areas.

 

“The first is we all have the mandate across the federal space to share business solutions. We need to make sure that when we build applications, whether it’s case management applications, whatever,  that we are doing the best we can to share those solutions across organizational boundaries and that’s a rational for SOA, so that gives us some tools for doing that,” Paul said.  Second is sharing information. “It’s a big, big driver. It’s huge across the federal government and SOA is a best practices implementation framework to do that”, so that’s another rational for doing SOA.”

 

Then there is sharing infrastructure. “We spend a lot of money across the government on infrastructure and there’s a real opportunity to share infrastructure because of the standards based approaches with SOA so that the computer infrastructures can be shared.” A great example of that in the private sector are Amazon and Google, where in their “cloud” they provide the ability for developers to build and use storage and compute cycles on a pay-per-use basis, the so-called utility model for  computing. “You enable with a SOA framework,” said Paul.

 

The PGFSOA has been developed to meet
the unique challenges the federal IT
community has to address.

 

“A fourth rational is to share acquisition power,” Paul continued. “One of the pretty exciting ideas behind SOA is you can enable a market place where you can actually buy specific services. You see this in the private sector where there are so called mash-ups. There’s a whole ecosystem around Google maps where they are building applications where they take data and mapping services and put those together.” While the Google model is advertising supported, the time has come where you can buy specific services such as mapping services, data analytic services, credit card services, procurement and purchasing services and pay for those on a per-service basis and so that’s the kind of idea that SOA helps you enable.

 

“The last one is sharing technology practices,” Paul said. “Again there is a rich body of best practices and standards that are open standards around SOA so there’s an opportunity there to look at how we build systems and how we manage the development process and the like. So those are the five key drivers.”  The sixth are the mandates, the EA mandates, the security mandates and again SOA gives you a way to be able to look at those mandates and be able to address them effectively according to Paul.

 

Three Layers

So what does this all look like?

 

Paul said they are divided into three layers: service oriented infrastructure, service oriented architecture and service oriented enterprise. “In each of those layers we are putting out guidance again rooted in what we think is leading best practices and open standards.” Paul said. “Service oriented infrastructure is a classic formulation. It looks at things like enterprise services and basic types of coding standards.” “Service oriented architecture represents a style of how you decompose business requirements in the services,” explained Paul. “One of the classic areas in service oriented architecture is how you go from high level business services to fine grained services that you actually code to. So that process again is very much driven by what are your requirements. What are you trying to build? So that’s kind of service oriented architecture.”

 

“Service oriented enterprise goes to a lot of the organizational transformation and governance issues,” noted Paul. “How do you work charge back models? How do you work service levels? How do you do cost accounting? How do you make sure you drive the road map for the requirements in a way that all the stakeholders across the different organizational boundaries, their equities are represented?” According to Paul a lot of people talk about governance being the hot button inside of SOA. “But if we think about that as a service oriented enterprise. One of the observations is that to really realize a lot of the benefits; there’s a degree of organizational transformation that has to occur.”

 

This goes back to the idea of what’s unique about the federal government and crossing organizational boundaries. People have to learn how to share across organizational boundaries. “You can’t take that as a given. That’s the thing that requires organizational change. It is a cultural change. So even though the technology enables it, it doesn’t mean that the organization is ready to implement it successfully.”