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.

He calls his office the Office of Horizontal Government.

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.

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.” ■

October, 2008 • Volume 6 • Number 10
 

SOA: Health Care Enabler

SOA is at the heart of the health information exchange movement.

Even though the benefits are obvious, major challenges exist to make health information available online at the different stages of patient care.

Deck

For many it may be a matter of life or death. Maybe that is being dramatic, but having the right patient information in the right hands at the right time does make a difference.

The drive to electronic health records and the seamless sharing of patient information is on ongoing movement within the American healthcare community. But it has not been easy, nor or we ready to declare victory.

That’s why we should be cheering the efforts of dedicated professionals such as Vish Sankaran, the program director for Federal Health Architecture at HHS.

During a recent appearance on the Federal Executive Forum on SOA, Sankaran spoke about his role in Federal Health Architecture. “It is made up of over 20 federal agencies. And the role here is to build tools and solutions for federal agencies, to have cross agency collaboration and also to implement interoperable health information solutions across the federal government.”

That collaboration was demonstrated at HHS headquarters in Washington, DC in front of two cabinet level secretaries on September 23. “I’m happy to report that we were able to demonstrate live exchange of health data,” proclaimed Sankaran. “These were tests with live data across the country around 15 different health information exchanges. That is something we can all be proud of. It’s a new chapter in the ongoing effort to improve quality of health care for the citizens of this country.”

Sankaran is working within a SOA model to enable health IT collaboration and firmly believes that the architecture must be business driven.

“We have learned that the hard way with the Federal Health Architecture Initiative, where it was initially focused on just architecture work,” explained Sankaran.

“But over the years the way we have brought agencies together is by looking at the business priorities of these agencies. Every agency has their own set of requirements that they need to meet and the mission goals that they need to meet. What we did is look at the business drivers and then try to use architecture to achieve that particular goal and build solutions along with it.”

“The nationwide Health Information Network Initiative that we’ve talked about is such an initiative,” Sankaran said. “What we did was at the Office of the National Coordinator – at the national level -- brought multiple health information exchanges providers to the table for the exchange of health information.”

Around the table these health IT leaders first had to answer the question about what was the federal role in this?

“How do you bring all the federal agencies, the different missions, different priorities, how do you build a set of common services? How do you build a SOA for this kind of activity? It was very interesting when we started but as we started looking at business priorities and giving more emphasis on business needs, and then using architecture to support it, there was a lot more buy in from the agencies,” Sankaran noted.

Challenges – And More Challenges

Despite buy in, challenges still exist and must be overcome. “Let me just paint the scenarios that we face in the health care world and for any of us that are citizens of this country,” Sankaran posed.

“We walk into hospital and we all have to fill out those 8 or 9 page clipboards. Or someone like me who is a cancer survivor has to go through multiple specialties and information is critical there. I need to make sure the information is all connected,” explained Sankaran.

To further make his case he talked about the American soldier, sailor or airman serving his country. “Think of a wounded soldier who comes back who needs, who lacks cognitive skills. And who becomes the health information exchange for all these people? How do you make sure the information flows from different specialties within the hospital? It is their families. So these are challenges that we have in health care today,” Sankaran said.

According to Sankaran, they are working on the challenges related to how you connect all this data. “These are all going to be separate systems around the country. We will never have a large data base holding all the medical records of patients.

“It will never happen. We have to connect all these existing networks around the country. That is the biggest challenge we have. We have made some great strides towards bringing all these different participants and agreeing on common principles, common services, how you identify a patient across different systems. There are also some key challenges on security and privacy.”

These are some of the biggest challenges that the health care community faces according to Sankaran. “How can architecture help drive some of the business challenges. We always have to look at it from a different perspective and make sure the business community across these agencies, along with the architecture community, advance and go forward.”

Sankaran thinks the next administration is really going to have to use business driven EA and SOA to help improve health IT and reduce administrative costs.

“Let’s take another perspective of this. If we need to transform the health care industry; it is the biggest industry -- $2.4 trillion. And of which the federal government pays about 40% of that -- close to $ 1 trillion,” Sankaran said.

“Now, when we try to make these kinds of changes of moving the health care system to an electronic world from the paper based system that we have now, there are challenges with it, and the question is, how do we manage that kind of large change. How do we do it?” asked Sankaran.

“And it has to be a structured organized framework under which we need to operate to really make those small steps to achieving that goal. So I feel that enterprise architecture is here to stay as long as that is very tightly integrated with the business community and the business needs.”

Privacy and Security Are Paramount

“We all know that health information exchange, or making information available at the point of care will improve quality of health care. That’s a known fact,” said Sankaran.

“Even though the benefits are obvious, there are major challenges in making health information available at the different points of care with the movement of the data and making it available online,” explained Sankaran.   “There are activities within the federal government. The secretary of HHS will be releasing a privacy and security framework by the end of this year, for health information. Along with that we are also looking at the FISMA and HIPPA kind of security controls that are required by the federal agencies compared to the private sector,” Sankaran continued.

But questions remain. “How do you make sure there is some kind of a baseline that all the agencies can agree upon when we start moving into this production world of moving health information?” queried Sankaran. “So there’s an initiative within the federal health architecture bringing over 20 federal agencies together along with OMB and NIST to have discussions about federal security and strategy for health information exchange.”

Down The Road

Sankaran is confident that we are moving in the right direction and a few years down the road, we are going to be able to point back and say that came from this.

“When I think of where we are today about purchasing something on the Internet,” said Sankaran. “If I want to buy a car, I can go on line and check the quality of the car, the cost of the car, compare between them and when I walk into the dealership I can have all that information with me when I have these discussions.”

“Think of a world where in health care the consumer is, it’s more of a consumer centric health care system; where we have control of our health and we know where we can get the best services at a cheaper cost and a higher quality,” he pondered.

“So we are moving in that direction. Office of the National Coordinator has made great strides in the past 4 years. I’m not saying that because I’m from ONC, but if you look compared with the years before, the past 4 years has brought a lot of attention into this space of using IT as one of the key drivers transforming the health care system of the country.”

Sankaran is optimistic because he sees in the federal government a lot more collaboration going on right now, because now agencies are focusing more on the citizens’ needs.

“Because if you take a wounded soldier, it doesn’t stop with the DOD,” said Sankaran. “From DOD it moves over to VA and then there are interactions with Social Security, and interactions with CMS.”

“So we are looking at more of a service based system as we move forward. The government will be looking more from a citizen perspective, and the citizen shouldn’t be worried about what agency should I go to get my service. I think that’s where we are.” ■

October, 2008 • Volume 6 • Number 10
 

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. The PGFSOA has been developed to meet the unique challenges the federal IT community has to address.

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.

“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.”  ■

A SOA Future

Craig Muzilla, Vice President, Middleware Business Unit, Red Hat

“SOA is not new, it’s really a 20 year old concept, but I think the time is right, the time is appropriate for it to really make an impact on the world in terms of how it operates.

Because of SOA, you’ll see a lot more dynamic processes among agencies and businesses; you’ll see a lot more technology independence; and you’ll see a lot more collaboration. The concept, to give an example, in health care of a common patient record freely available is possible. I think you will begin to see that now because of this trend and I think it will have great benefits for everyone.”

Scott Bernard, DCIO, Director of IT/ISSO, Federal Railroad Administration, DOT

“I think SOA will continue to mature as a best practice both in driving a reorientation in thinking from programs and systems to services, as well as standards and products being harmonized more towards those services that are important to the agencies.

And the other thing is that EA as the overarching piece of governance is here to stay. Because as I said, I’ve lived through those bad old days when we had programs that were fighting for resources, systems that were duplicating functions, and we don’t want to go back to that.

EA is here to stay and it’s about much more than IT. It’s about strategy, business and technology planning, being integrated, the architecture being used and really EA is for CEOs I think as we move forward, and that’s an exciting proposition.”

Andy Hoskinson, Vice President & Partner, Technology Strategy and Consulting, Unisys Federal Systems

“I think a specific benefit that we will see in the next couple of years with SOA -- that will be huge and very popular with citizens -- will be more streamlined data collection that is more user friendly. 

And (you’ll see) better interagency information sharing. For example now if you go to the IRS you provide data, you fill out a lengthy form; you go to the Social Security Agency, you fill out a lengthy form. You provide a lot of the same kind of identity and profile information using different forms to different agencies. It takes a long time for citizens to fill out; and introduces the possibility of data collection errors.

I think what we are going to see with the successful implementation of SOA governmentwide; we’ll get to a place where a citizen might provide their profile in one spot and with the click of a mouse, the click of a button, decide which agency they want to submit it to depending on the particular activity they are performing.”

Kshemendra Paul, Chief Architect, OMB

“Well with the Federal Enterprise Architecture, what we are starting to see now is that there’s a maturity. We are seeing in the agencies, in the bureaus and the programs some of the different successes we’ve been talking about. We are starting to see a bottom-up target architecture start to coalesce, cross cutting segments like health IT or counter terrorism information sharing.

That view is becoming increasingly structured and allows us to provide feedback to the agencies on specific opportunities for collaboration. The original vision when this was started was something like this. You go back to the Quicksilver; the lines of business initiatives were done. What we are able to do now is to inform those kinds of analyses and activities with specific opportunities for collaboration and then drive that through the federal enterprise architecture.

I mentioned earlier the Federal Transition Framework. That becomes a key repository for that collaboration and reuse. It becomes the kind of thing where as agencies start what they are doing they are able to share architectures, share architectures around business services around enterprise service segments, for example identity management, or core mission segments like health IT. We are able to do that at plan time and to get to a coherent plan through the Federal Enterprise Architecture.”

Learn more about SOA. Go to www.egov.gov and www.CIO.gov. For information sharing activities go to www.NIEM.gov.

October, 2008 • Volume 6 • Number 10
 

Governing Principles

Governance is the key ingredient of the Practical Guide to Federal Service Oriented Architecture.

The vision we have for the Federal Transition Framework is really to become a market place for matching demand and supply for IT services and solutions

As with any horizontal movement, getting consensus from the many stakeholders is never easy. With SOA it is no different; there needs to be governance processes in place that allows stakeholder input, but at the same time moves the various layers of an organization towards a common destination.

“It’s a really crucial topic, an important topic for OMB especially in the E-Gov area,” declared Kshemendra Paul, Chief Architect at OMB during the recent Federal Executive Forum on SOA.

“We work very strongly with the Federal CIO Council and we look to them to help us with governance related issues. Particularly on the architecture side is the Architecture and Infrastructure Committee that I’m involved with.

It’s been a very active committee having just finished published in June 2008, The Practical Guide to Federal Service Oriented Architecture (PGFSOA) in partnership with the American Council for Technology and the Industry Advisory Council.

“It’s a document that people can find on the E-Gov web site and I’d encourage people to look at it,” said Paul. “We tried to identify what was unique about employing SOA in the federal space along with the governance issues and things like that.”

According to Craig Muzilla, VP Middleware Business Unit at Red Hat, part of what is unique about the Federal space are the up-front time in planning and setting an administrative and planning process where new services can be introduced.

“I think there’s also some technology that can play a large role here,” said Muzilla. “When you look at governance in SOA, you can look at it in two ways --design & build time and run time. And when you are looking at design and build time, I think you need to have technology and processes that address things like change management.”

A service is defined, but now there are always going to be changes said Muzilla. So how do you implement those changes? How do you map those dependencies? Do you know all the things that it ties to?

“Some technology can help in that area,” explained Muzilla. “On the run time side, you look at things like service levels. So there’s a service level agreement, but maybe one set of users has certain level of service that’s provided, and another set of users has another service level. So technology can play a role in the governance of the architecture.”

Paul added there is one other factor to be considered in the federal space. “We also have to be concerned with plan time. We have long planning cycles and budgeting cycles. Paul highlighted the role of the Federal Transition Framework especially around looking at opportunities for collaboration.

“At the very front of the process when people in agencies, bureaus, programs are doing their initial architecture, preparing their 300s investment proposals, a key step is the collaboration and reuse,” Paul remarked. “Not to reinvent but to look at the Federal Transition Framework and be able to pull down shared architectures, solutions, services, information. And the vision we have for the FTF is really to become a market place for at plan time matching demand and supply for IT services and solutions. So it’s an important idea.”

At the Federal Railroad Administration, they are in their 6^th year of a capital planning process that includes enterprise architecture, program management, work force management and cyber security elements according to Scott Bernard, Deputy CIO.

“I think most important persistent features in annual activities in agencies is the budget process and the capital planning process and then reviewing our portfolio of investments in information technology,” said Bernard.  

Bernard said the Federal Railroad Administration has quarterly planning meetings in which executive leadership takes part. “We use them as an opportunity to ask the essential questions on the business and the technology side related to enterprise architecture.”

“We start with the requirement solution fit, and then we talk about standards, and then we talk about earned value management, cost and schedule, performance control and then we finish with risk management and security solutions,” Bernard explained.

“I think that leadership and program managers really appreciate that it’s a mature process, that they know when things are going to happen, and they know that the oversight is really multifaceted and they are prepared for that and it’s really helped us to manage our investments and leverage our resources to the maximum level possible.”

Unisys’s VP of Technology Strategy and Consulting, Andy Hoskinson  agrees with Bernard saying that if you don’t have a high quality product, then it’s going to be much more difficult to implement it, even with the strongest governance processes in place.

“You have to do is you really have to be joined at the hip with the people who do capital planning and budget formulation and execution, so that as business units and programs propose initiatives, you have a robust and transparent process that uses the enterprise architecture work products to assess those proposed IT investments to make sure they make sense given the strategic direction of the agency,” said Hoskinson.

“As you have a high quality EA blueprint road map; as long as you have a transparent process by which a program executive or a program official can propose an investment and say ‘here is my business case for this investment’, people are going to buy into that system and they are going to be able to live with the results.”

October, 2008 • Volume 6 • Number 10
 

SOA: Evolving Challenges

SOA faces a number of challenges as it moves from conceptual guidelines to practical mainstream use.

SOA is a good way to integrate the business data and application levels into that enterprise wide architecture. And there are a lot of mature best practices now on how to do SOA within the context of EA.

Understanding leads to implementation. Understanding SOA however has not been easy. It is shared services? Is it software reuse? Does it mean I lose control of my system?  Implementing SOA is filled with challenges.

“One challenge is understanding the relationship between enterprise architecture and service oriented architecture and then using both of those to improve mission performance,” explained Scott Bernard, Deputy CIO at Transportation’s Federal Railroad Administration during the Federal Executive Forum on SOA.

“I believe the relationship is that EA is the overarching approach and most EA frameworks that I’ve seen have a strategy business data application and infrastructure level to it,” Bernard said.

“As far as I’m seeing, SOA is really a good way to integrate the business data and application levels into that enterprise wide architecture. And there are a lot of mature best practices now on how to do SOA within the context of EA.”

OK, that’s a technical challenge that certainly can be overcome. “But the other challenge I see is getting executives to be involved with the architecture and to support it and understand the value of the SOA effort within the EA context.”

Bernard thinks this is crucial to clearing obstacles because as we architect organizations we are often overlooking the cultural aspect of change. If they use those architecture products and the approach to rework business processes, its helps control costs.

“So I think leadership involvement, understanding the relationships of EA and SOA and then helping to use the architecture for planning the decision making are some of the things that we still are addressing.”

Kshemendra Paul, Chief Architect at OMB agrees.

“Looking at it from the OMB perspective, we see things across government as well as across all the different management processes,” declared Paul. “We want to break down the barriers and break down the silos.”

Paul warns that we need to guard against siloing of management processes in areas such as the strategic planning activity, the program performance analysis, the architecture activity, the capital planning, the budgeting, program oversight and year over year sort of analysis.

“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,” counseled Paul.

Partners In Progress

SOA is not a government only activity. To make it work takes solutions from the private sector.

One of those companies involved in making SOA work is Red Hat. Craig Muzilla is VP of Red Hat’s Middleware Business Unit.

Some of the challenges from an industry side deal with the evolution of the technology that is working to catch up with some of the government’s real-life needs.

“Things like security and some of the standards associated with SOA are still evolving,” said Muzilla. “I think primarily though some of the biggest challenges are within the organizations that use SOA. For instance what granularity of service, how do you define the service? Is it really defined in such a manner that can be reused? Who has control over that service? Who has the rights and access to that service?”

Once again many of the challenges are organizational rather than technology. “A lot of the time as you are moving towards SOA is really spent on some of those organizational issues, some of those definitional issues,” added Muzilla.

Managing the cultural shift is also a concern to Andy Hoskinson, VP &   Partner, Technology Strategy and Consulting at Unisys Federal Systems.

Hoskinson talked about the ongoing issue of program control. “For any large enterprise, especially in government, it is a cultural shift because the executives who lead large programs in organizations are responsible for achieving a particular outcome and control the resources to achieve that outcome,” said Hoskinson.

It’s not easy for executives to give up the control over resources they deem important to the success of their mission. It’s hard for them to say “I’m going to have to trust an external organization that’s going to provision a service, and manage to a service level as opposed to managing directly people and other resources.”

But on the other side of the coin Hoskinson said, “When you do a shift to SOA you end up having individual business units that end up provisioning a shared service that become a center of excellence or a shared service center because they deliver a particular service at a high quality.”

As a result they essentially become an IT support organization and they have to learn to behave that way, develop the customer service, guarantee a particular service level and that doesn’t come automatically. It requires training, it requires a governance framework that requires appropriate policies and incentives to help manage that cultural shift according to Hoskinson.

Transition planning can derail even the best SOA strategy Hoskinson warns. “You might understand the risk involved in transitioning legacy systems to using shared services,” explained Hoskins.

“When you are creating a transition plan, you really have to understand completely the risks involved; risk of reduced service levels, increased down time and data loss; risk of interfering with a mission operation by not understanding the milestones that are important to the mission side of the house.”

Hoskinson urges managers to spend a lot of time doing that to manage that risk to make sure that you don’t derail your entire organization. ###

October, 2008 • Volume 6 • Number 10
 

What The PFGSOA Says

Here is what The Practical Guide To Service Oriented Architecture (PGFSOA) has to say about the challenges SOA faces.

The process of reconciling the Enterprise Architecture’s IT services portfolio, both intra-agency and cross-agency, frequently results in conflict when two or more programs have an interest in a given service type. Conflict is, in part, due to a lack of an enterprise-wide SOA framework and may be grouped into at least four major challenge categories (politics aside):

1. Lack of an operational or target model for federal enterprise-wide SOA environment;

2. Lack of understanding and experience in implementing SOA at the agency/department-level;

3. Lack of procedures/guidance for consuming enterprise services in lieu of local services; and

4. Lack of operational services management; particularly for cross-agency services once implemented.

A key characteristic of SOA is modularity that facilitates/enables service reuse across processes and organizational boundaries. A service that is designated for reuse or as an enterprise service, such as authentication, must reside in an environment that is discoverable, reliable, maintainable, and can be monitored. An overarching architecture is needed to contain these services as they are developed and implemented. Further complicating this is the need to support service reuse at multiple levels – between programs, between bureaus, between departments, and so on.

The discipline of enterprise-wide SOA is immature in the federal government. For example, for any large federal organization, reuse of services across processes and between contractors is rare. While organizations may have a “repository” that is used (like a library) to check services in and out, it often fails to support a true SOA model. As a result, training and mentoring are needed to fully leverage the benefits of SOA within and across the enterprises.

The third challenge that creates conflict has two dimensions. The first dimension concerns the consequences of promoting a locally developed service up to an enterprise-wide or cross-agency level. Often, there are no procedures and/or compensation for the development of the service that is to be used by two or more entities. Related to this are the issues of quality of service (QoS) obligations of the original developer as consumption of the service increases (for example, as the service designed to support 100 transactions per second now needs to support 10,000 transactions per second) and the functional responsibility for the service (i.e., who is responsible for implementing changes to critical business rules of the service).

The second dimension concerns the reality “after the fact” that stand-alone SOA-based systems have been implemented and are in development. Should these systems be required to adopt the declared enterprise-wide services as an outcome of the organization’s Enterprise Architecture, even though the services may not meet 100% of the requirements? This challenge is addressed in Sections 4 and 5.

The fourth challenge is associated with business management of services, including QoS standards and Service Level Agreements (SLAs). This challenge can be illustrated by analogy. Networks are closely monitored in “War Rooms” with banks of screens to monitor network performance.

As the network experiences performance problems, engineers can quickly respond and in most cases resolve the issue before the problem cascades throughout the network. Returning to services, which are implemented within and across enterprises, the performance of each service and the interaction between services also needs to be monitored to ensure the business output and outcomes are achieved. 

SOA Improves Services

Below are excerpts from the Practical Guide to Federal Service Oriented Architecture (PGFSOA), published in June 2008 by the CIO Council in collaboration with the American Council of Technology and the Industry Advisory Council.

SOA and Enterprise Architecture

SOA does not replace Enterprise Architecture (EA). At each stage in the EA lifecycle, a set of activities is conducted to service-orient the EA. While the activities noted on the inner circle of the diagram are not intended to be exhaustive, they do indicate the types of activities organizations must undertake to implement SOA. These activities are discussed throughout this document with explanations and examples of how to accomplish the tasks.

SOA Challenges

The process of reconciling the Enterprise Architecture’s IT services portfolio, both intra-agency and cross-agency, frequently results in conflict when two or more programs have an interest in a given service type. Conflict is, in part, due to a lack of an enterprise-wide SOA framework and may be grouped into at least four major challenge categories (politics aside):

1. Lack of an operational or target model for federal enterprise-wide SOA environment;

2. Lack of understanding and experience in implementing SOA at the agency/department-level;

3. Lack of procedures/guidance for consuming enterprise services in lieu of local services; and

4. Lack of operational services management; particularly for cross-agency services once implemented.

A key characteristic of SOA is modularity that facilitates/enables service reuse across processes and organizational boundaries. A service that is designated for reuse or as an enterprise service, such as authentication, must reside in an environment that is discoverable, reliable, maintainable, and can be monitored. An overarching architecture is needed to contain these services as they are developed and implemented. Further complicating this is the need to support service reuse at multiple levels – between programs, between bureaus, between departments, and so on.

The discipline of enterprise-wide SOA is immature in the federal government. For example, for any large federal organization, reuse of services across processes and between contractors is rare. While organizations may have a “repository” that is used (like a library) to check services in and out, it often fails to support a true SOA model. As a result, training and mentoring are needed to fully leverage the benefits of SOA within and across the enterprises.

The third challenge that creates conflict has two dimensions. The first dimension concerns the consequences of promoting a locally developed service up to an enterprise-wide or cross-agency level. Often, there are no procedures and/or compensation for the development of the service that is to be used by two or more entities. Related to this are the issues of quality of service (QoS) obligations of the original developer as consumption of the service increases (for example, as the service designed to support 100 transactions per second now needs to support 10,000 transactions per second) and the functional responsibility for the service (i.e., who is responsible for implementing changes to critical business rules of the service).

The second dimension concerns the reality “after the fact” that stand-alone SOA-based systems have been implemented and are in development. Should these systems be required to adopt the declared enterprise-wide services as an outcome of the organization’s Enterprise Architecture, even though the services may not meet 100% of the requirements? This challenge is addressed in Sections 4 and 5.

The fourth challenge is associated with business management of services, including QoS standards and Service Level Agreements (SLAs). This challenge can be illustrated by analogy. Networks are closely monitored in “War Rooms” with banks of screens to monitor network performance.

As the network experiences performance problems, engineers can quickly respond and in most cases resolve the issue before the problem cascades throughout the network. Returning to services, which are implemented within and across enterprises, the performance of each service and the interaction between services also needs to be monitored to ensure the business output and outcomes are achieved.

Improving Services from Federal Agencies

This practical guide is organized around three perspectives of service orientation that together enable the effective adoption of SOA into a federal organization. For each of these perspectives, we characterize the objectives of a mature SOA capability. These are the objectives that each federal organization adopting SOA should strive to achieve in order to achieve its maximum benefits.

·         Service Oriented Enterprise (SOE) consists of the organizational and managerial practices needed to enable and govern SOA. SOE establishes trust and includes the incentive model that drives mutually profitable collaboration among service providers and consumers.

·         Service Oriented Architecture (SOA) is the body of standard design and engineering processes, tools, and best practices that leverage the modularity and composability of services to support business objectives. SOA deepens and extends the Enterprise Architecture and defines the implementation of the architecture in terms of its technical approach.

·         Service Oriented Infrastructure (SOI) is a collection of functioning capability, including technology, standards, and collaborative processes that enable safe (i.e., secure and private) and efficient collaboration through the development and deployment of shared operational IT services. SOI decreases the risk of security and privacy breaches by implementing standardized infrastructure components and services.

Keys to Federal SOA Implementation

There are critical strategies and tactics that have been demonstrated to be effective at facilitating SOA adoption. In general, the intention is to de-couple the business objectives from the complexity of the IT infrastructure by developing a target service-based business model.

Then, a services architecture needs to be developed with the specific objective of aligning program and project based DME (development, modernization, enhancement) funding to incrementally re-capitalize IT assets against the most critical business drivers, as well as encourage planned or immediate reuse of emerging or existing services rather than making duplicative investments.

Early on, the challenge has been to balance the incremental demands on program and project teams – delivering for their immediate customers as well as the requirements of the broader enterprise. Later on, the objective is to balance the inter-twined dependencies - requirements, service levels, and funding models to name a few - in a way that results in increased organizational agility and improved mission performance. Both require strong leadership and effective governance.

Keys to Implementing the Service Oriented Enterprise

·         Ensure IT planning and acquisition processes capture service reuse and funding requirements and target architecture technology constraints. Build alignment into the SDLC so it is automatic.

·         Identify enterprise requirements and organize around target services, standards, and information sharing that support key mission performance objectives; then fund accordingly.

·         Develop incrementally. Employ an incremental “lifecycle recapitalization” approach and modify the SDLC to support a twin-track development process with separation between service provisioners and solution assemblers.

·         Federate governance, engineering, and procurement. Leverage existing agency and cross-agency governance processes to support the Federal E-Government initiatives, LOB initiatives, and other initiatives such as NIEM to enhance SOA implementations.

Keys to Implementing the Service Oriented Architecture

·         Identify critical business objectives. Perform business process analysis and reengineering and sustain accurate service-based business models for business automation requirements.

·         Identify and define the target service architecture. Establish a layered service architecture that directly supports the business performance objectives. Introduce “service” as a first order concept in your enterprise architecture. Integrate existing and emerging cross Government and cross agency services, ideally driven out of agency segment architecture activities.

·         Enable and empower autonomous compliance and alignment. Define and publicize the enterprise service portfolio plan and phased transition strategy. Note that this works best where you have the most detailed roadmaps, thus start with the core mission or business activities, or cross cutting services where you have developed segment architectures.

·         Adopt model-driven architecture and pattern based design. Establish model-based reference architectures and reference implementations. Start by bridging from segment to specific solution architectures.

Keys to Implementing the Service Oriented Infrastructure

·         Establish a service oriented infrastructure that addresses security/privacy, scalability, and interoperability. In particular, leverage secure virtualization approaches to clearly separate the shared security, transport, storage, and compute capabilities from individual services and solutions.

·         Study critical transactions to develop a trust and semantic model. Invest to develop standard government security services; test and certify adaptively and continuously. In particular, look to align with and adopt existing and emerging cross Government solutions, and improve them as needed via established governance models. Isolated agency-based solutions, no matter how good, run the risk of impeding downstream cross Government interoperability.

·         Introduce run time service monitoring tools. This includes monitoring and management across all relevant targeted attributes – security, privacy, reliability, serviceability, and availability. This is another area where it is important to align with and adopt existing and emerging cross Government approaches to ensure that creation of artificial boundaries for sharing, reuse, and interoperability are avoided.

·         Establish performance-based service levels and service level management processes and cost and performance accounting processes to facilitate the effective sharing of services. Look to express these service level agreements in shared, Government-wide structured IT policy frameworks.

Roadmap for Federal SOA Implementation

The purpose of a roadmap is to establish direction, identify the contributing factors (or work areas), and determine the specific steps to undertake within each of these areas. The first step in any roadmap is to perform an assessment – an evaluation of how SOA can be an enabler to help an organization to achieve its goals or implement its strategies. The assessment should examine organizational strengths, weaknesses, and actuators in context with the opportunities associated with SOA.

·         Apply a relatively generic SOA Maturity Model that outlines the stages of maturity through which organizations go to implement and operate a Service Oriented Architecture.

·         Conduct a sound Maturity Assessment to determine the organization’s level of maturity in relation to each SOA contributing factor. Consider governance, service orientation, technology environment, management commitment and perspective, technical skills, and capabilities.

·         Evaluate existing agency governance processes and agency participation in Government wide and other external governance processes, in light of the results of the Maturity Assessment and determine adjustments that are necessary to encourage and support Service Orientation.

·         Begin or advance SOA implementation to identify priority areas based on the SOA maturity assessment and balance achievements in each of the work areas.

·         Define an incremental, sequenced approach to agency implementation to deliver frequent, small, but visible successes and to capture and exploit best practices.

Implementing the recommendations contained in this Practical Guide will initiate a “journey” within the Federal government towards greater effectiveness and efficiency for both IT and the business/mission. The result of this journey will be an enhanced degree of responsiveness to the citizens and an improved ability to respond quickly to new requirements and situations.

Source: Excerpts from A Practical Guide to Federal Service Oriented Architecture, June 30, 2008