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

Architecture: A 12 Letter Word For Having A Plan
Breaking down silos is a major objective of Service Oriented Architecture (SOA)
 
Kshemendra Paul’s job title is Chief Architect at OMB. And he is leading the broad-based adoption and advancement of Service Oriented Architecture (SOA) capabilities throughout the federal government.
 
“I work in the Office of E-Government and Information Technology, but most days I think of it as the Office of Horizontal Government,” said Paul during the recent Federal Executive Forum on SOA.

 

 

For Paul, a major challenge for government is moving from being a vertical organization – steeped in silos – to one that thinks and acts horizontally.  “We are organized by agencies, bureaus and programs. Money is appropriated that way, people grew up that way. Getting people to think across boundaries and being able to work across boundaries is really the key challenge.” While government has made horizontal progress, there is still much to be done to break down barriers and break down silos.

 

“One of the things that we see is that we have to guard against the siloing of management processes. We need to go from good intentions to societal impact; there’s a lot of different management processes and many of those  processes are overseen by OMB.” Paul talks about things such as the strategic planning activity, program performance analysis, architecture activity, capital planning and budgeting and program oversight. “We need to make sure that the outcomes at each step of those processes are linked to the next step. That’s how we move out of the compliance sort of architecture to the results-oriented architecture, by making those linkages clear,” said Paul. SOA is a key ingredient in government’s move to a results-oriented architecture.

 

What SOA Promises

Service Oriented Architecture is not a new concept. A service-oriented architecture is essentially a collection of services. These services communicate with each other. The communication can involve either simple data passing or it could involve two or more services coordinating some activity. Some means of connecting services to each other is needed. According to the Practical Guide to Federal Service Oriented Architecture (PGFSOA) published in June 2008 by The Federal CIO Council in collaboration with The American Council for Technology and the Industry Advisory Council:  “SOA promises to help agencies rapidly reconfigure their business and more easily position IT resources to serve it. Through it they will improve business agility – through the sharing and reuse of infrastructure, services, information, and solutions.”

 

The PGFSOA further states that SOA is a key component of any Federal EA whose need will become increasingly critical in the future.

 

SOA promises to help agencies rapidly reconfigure
their business and more easily position IT resources to
serve it. Through it they will improve business agility –
through the sharing and reuse of infrastructure, services, information, and solutions.

 

And while “these benefits have been promised in past waves of IT innovation. This time, they are enabled by the concurrent maturation of Internet-based IT standards and best practices and the adoption of those interoperable standards as a common fabric by stakeholders – Citizens, Government, Industry.”

 

Defining SOA

There are a number of things that must work together in order for SOA to succeed. Just adopting service-based technologies alone will not enable agencies to achieve the benefits associated with SOA.  The PGFSOA defines a service as “The means by which the needs of a consumer are brought together with the capabilities of a provider.” It employs an industry standard definition of SOA: “Service Oriented Architecture is a paradigm for organizing and utilizing distributed capabilities that may be under the control of different ownership domains.”  

 

SOA has organizational, governance, business process, structural, and technical dimensions that must be managed and synchronized according to the PGFSOA. It was created to help Federal chief architects and CIOs in “their efforts to adopt SOA best practices to further their organization’s mission, meet increasingly demanding compliance requirements, introduce more agility into their architecture, and optimize their IT architectures.”

 

SOA Rationale

By adopting and advancing the SOA capability governmentwide according to the PGFSOA, the federal government will enable:  Improved government responsiveness: By employing services to establish a flexible architecture centered on business and technology capabilities, business processes can be more easily modified to meet business and mission performance requirements.

 

Simplified delivery of enhanced government services: SOA and the “service” business model enable collaboration by simplifying access to services and streamlined value chains across organizational boundaries. More efficient government: SOA facilitates mutually leveraged public and private sector investment; reuse of capability; elimination of undesirable redundancies; and a more focused model for on-going IT recapitalization.  Information sharing: SOA provides an effective and efficient approach to implementing reusable data exchanges.

 

Transparency, security, and resilience: SOA is predicated on a shared, standards-based infrastructure. This will enable consolidation, simplification, and optimization of IT Infrastructure. The primary risk of SOA is when its application is not effectively governed with purposeful intent – in other words, the business agility SOA promises cannot be achieved through ad-hoc application of SOA technologies. “Business agility must be purposefully designed into each organization’s Enterprise Architecture, IT Governance, and IT Policy framework and implemented incrementally with each step tied to delivered business value.

 

The Business Context

Paul counseled that SOA is not just a “silver bullet” solution you can go out and buy. “It’s got unique characteristics and you don’t get the benefits of any of those business cases just by saying I’m going to go out and buy a SOA from my local vendor.” “It’s got to be in the context of a business project with a business sponsor,” explained Paul. “So SOA is a technique, but it helps you enable those benefits and realize those benefits and but in and of itself you don’t get those benefits by doing SOA. So that’s a really important idea that we are clear on and we are communicating through our Practical Guide.”

 

“You still have to do the hard work of understanding your business, being able to articulate it, getting in place across the organization and being able to justify the investment,” said Paul. “Then you can say now I need to come up with a solution architecture; and SOA approaches are a good way to go at that point; they represent the culmination of the best practices.”

 

SOA – Not Scary 

So, what does this all mean? When asked by 1105 Custom Media during a 2007 interview, “what are three things you need to know about SOA”, noted SOA expert and consultant David Linthicum said: “Number one is SOA is nothing scary, and it’s basically a different way of doing many of the things that we’ve been doing for the last 30 years. No need to panic. That’s the key thing. We have tried to get services reuse for a long time and agility for a long time and none of that has changed. We are just doing that with a new set of technologies and a new approach. 

 

Number two is success of SOA is directly linked with good planning, design, and architecture. And then I would say SOA is something you do, not something you buy. That’s a key thing.And number three is you need to justify the use of SOA within the business context; that means calculate the short term and the long term return on the investment, considering both the concepts of agility and reuse.