 | Level: Intermediate Judith Myerson (jmyerson@bellatlantic.net), Systems engineer and architect
10 Jan 2008 Look beyond the technical aspects of Service-Oriented Architecture (SOA)
adoption. This article focuses on the cultural considerations across organizational
boundaries in the federal sector. See examples of how you can build blocks of SOA
while maintaining adherence to appropriate organizational cultural aspects.
Introduction
My recent developerWorks series,
Work
with Web services in enterprise-wide SOAs
, covered notifying Web services and Enterprise Application Integrations
(EAIs), integrating radio frequency identification (RFID) Web services into EAI
applications, and developing risk management Web services. In the same series, I
looked at migrating legacy service components as discoverable Web services,
developing Repository Web services for the Service Integration maturity model
(SIMM), and capturing object patterns and relationships for UML modeling.
My other developerWorks series,
Use SLAs in a Web services context
, talked about mitigating risks for vulnerabilities and integrating Web
services into EAI, all with an Service Level Agreement (SLA) guarantee.
While all of these items show that SOAs are associated with Web services, you can
implement SOA using any service-based technology with loose coupling among
interacting software agents. All show SOA as a paradigm shift from IT as a
technology provider to IT as a business enabler, and the resulting cultural shift
in the way IT is done.
This article looks closely at the cultural considerations involved with SOA
development and implementation in the federal sector. Here you learn:
- The process of adopting SOA with an SOA reference model, an SOA maturity
model, and SOA governance.
- What's missing from the Federal Enterprise Architecture (FEA).
- Suggestions for managing cultural changes in the federal sector.
SOA reference model
The SOA reference model provides a foundation for building discoverable, reusable
services central to a federal agency's mission. On top of this foundation is the
SOA maturity model to gauge the quality and maturity of SOA adoption by the
agency. SOA governance provides the mechanisms to control the desired behavior of
the organization as the SOA adoption matures.
One model example is the Office of Management and Budget (OMB) FEA. Also known as
the Component-Based Architecture (CBA), this model focuses on providing services
to citizens, not to other SOA participants.
As illustrated in Figure 1, the FEA starts with the Performance Reference Model (PRM), followed by the lower
layer of the Business Reference Model (BRM). Next is the Service Components Reference
Model (SRM), which is built upon the Data Reference Model (DRM) and Technical
Reference Model (TRM), plus a security and privacy profile that describes how to
integrate information security requirements into the reference models.
Figure 1. Federal Enterprise Architecture
The
following sections focus on these layers.
Service Components Reference Model
The SRM is structured across horizontal and vertical service domains that can
provide support for the reuse of applications, application capabilities,
components, and business services. It's independent of business functions.
Business Reference Model
Immediately above the SRM's layer is the BRM, which describes and analyzes the
day-to-day business operations of the federal government. While many models exist
for describing organizations, such as organizational charts, location maps, and so
forth, the BRM presents the business with a functionally driven approach for
providing services to citizens.
Performance Reference Model
The next layer is the PRM, which provides the framework for measuring the
performance of major IT investments and associated assets. As of this writing, a
few agencies haven't yet submitted a list of what the results should be, as there
might be differences in the way outcomes are developed during the agency budget
and strategic agency planning process.
Technical Reference Model
Below the SRM layer is the TRM to categorize the standards, specifications, and
technologies to construct, deliver, and exchange business and application
components. The TRM includes service requirements for hosting that refers to the
service provider who manages and provides availability to a Web site or
application, often bound to an SLA.
Data Reference Model
Next layer down is the DRM, which provides a framework to describe, categorize,
and share data in a standard way. The standardization of describing data provides
a means for an SOA community to agree to the interoperability of both the
structure (syntax) and meaning (semantics) of the data. For information-sharing
infrastructures to be successfully implemented, problems with different contexts
and their associated meanings between content owners using SOAs must be resolved.
What's missing from the
FEA
What's apparently missing from the FEA is the SOA Security Reference Model
(SSRM), which allows it to go beyond the security and privacy profile. The SSRM
helps to address the security requirements of the SOA due to increased exposure to
risks and vulnerabilities of loose coupling of the services and operations across
organizational boundaries.
SOA security must be factored into the SOA life cycle, reflecting the fact that
security is a business requirement and not just a technology attribute. By
including security in SOA life cycle management, all documents must be evaluated
to ensure that security requirements are met. An SSRM helps address the security
requirements of SOA, as security is applicable to the entire SSRM—across
infrastructure, application, business services, and development services.
This model consists of IT security services, security policy infrastructure,
business security services, and security enablers. Governance and risk management
provide the mechanism to implement and enforce security policies within the larger
SOA environment. The SSRM has also been the subject of interest in military
software engineering.
SOA maturity model
To find out where your agency stands in adopting SOA, the first step is to employ
an SOA maturity model. In each maturity stage, your agency's measurements should
point out its strengths and weaknesses as well as gauge its improvements. One
problem is that the model can't skip a stage as it moves up the maturity level or
go backwards to update process activities as a result of the changes in the
organization's role (such as major reorganization).
One solution is to develop Web services to supplement the maturity model, such as
the IBM Service Integration Maturity Model (SIMM), considered the most flexible of
all Capability Maturity Models (CMMs). Because of this flexibility and the SIMM's
ability to adapt to changes in service integration process activities as a result
of new technologies and the cultural aspects of the SOA, developers can build Web
services (see
Part 16
in the Work with Web services in enterprise-wide SOAs series) as a
supplement to the SIMM's simple, composite, virtualized, and dynamically
reconfigurable services.
SOA Governance
In SOA the consumers and providers of services run in different processes, are
developed and managed by different departments and agencies, and require a lot of
coordination to work together successfully. To achieve the desired behavior of an
organization as the SOA adoption matures, you need to apply an SOA governance
model to establish and enforce agreements between the providers of services and
the consumers of those services. These agreements tell the consumers what they can
expect and the providers what they're obligated to provide to get multiple
applications to share common services and make those services reusable.
SOA governance determines and plans for:
- Who is responsible for making decisions.
- What decisions need to be made.
- What policies are necessary to guide the organization to meet its goals.
- What measurement technique is needed to gauge the effectiveness of governance.
- What control mechanisms are required to ensure compliance.
SOA governance guides how the services change over time. It's important to keep
all required parties informed on governance issues, such as compliance to changing
standards or laws; setting compliance, performance, and security policies; change
management of the cultural shift; and ensuring quality of services.
Handling cultural
aspects
Here are some recommendations for handling cultural aspects of the SOA:
- Evaluate an agency mission if it's focusing on GUI-based services for citizens
or GUI-less intrajoint services.
- Consider the SSRM to address security requirements for the SOA.
- Supplement an SOA maturity model with Web services to update changes in
process activities of a service provider.
- Make sure standards guarantee interoperability both at the syntactic and
semantic levels.
- Get the service provider and consumers to agree on testing methods to ensure
correctness of services in the SOA.
Conclusion
You need a team of developers, testers, system administrators, and potential
federal SOA participants to consider cultural aspects of SOA adoption. To handle
the cultural aspects, you must plan developing, testing, and deploying federal SOA
projects ahead of time. Resolving these issues makes your job handling cultural
aspects of SOA adoption a lot easier. You can use IBM® Rational®
ClearQuest®, IBM Rational Tester for SOA Quality, and IBM Rational
Functional Tester to increase productivity by reducing testing and defect tracking
time as well as the costs of test labs in an enterprise SOA development project.
Resources Learn
- Check out the
Work
with Web services in enterprise-wide SOAs
series by Judith M. Myerson.
- Read Judith's series
Use SLAs in a Web services context
for details on service-level agreements.
- IBM Redbooks®: Learn more about SOA Security Reference
Model in "Understanding SOA Security Design and Implementation."
- Collaborate with others who are interested in
SOA in the federal sector in the
Federal SOA Institute - SOA Certification Mentoring
discussion forum.
- Read Judith M. Myerson's
The Complete Book of Middleware
, which focuses on the essential principles and priorities of system design and
emphasizes the new requirements brought forward by the rise of e-commerce and
distributed integrated systems.
- Get the business insight and the technical
know-how to ensure successful systems integration by reading
Enterprise Systems Integration, Second Edition
.
- Bring your organization into the future with
RFID in the Supply
Chain
, which explains business processes, operational and implementation problems, risks,
vulnerabilities, and security and privacy.
- IBM Redbooks: Go into the nuts and bolts of developing a
service-level agreement in
Tivoli® Manager for Domino V2.1: Fulfilling Service Level Agreements Using Tivoli Technology.
- The SOA and Web services zone on IBM developerWorks hosts hundreds of informative articles and introductory, intermediate, and advanced tutorials on how to develop Web services
applications.
- Play in the IBM SOA Sandbox! Increase your SOA skills through practical, hands-on experience with the IBM SOA entry points.
- The IBM SOA Web site offers an overview of SOA and how IBM can help you get there.
- Stay current with developerWorks technical events and webcasts. Check out the following SOA and Web services tech briefings in particular:
- Browse for books on these and other technical topics at the
Safari bookstore.
- Check out a quick Web services on demand demo.
Get products and technologies
- Innovate your next development project with
IBM trial software, available for download or on DVD.
Discuss
About the author | | | Judith M. Myerson is a systems architect and engineer. Her areas of interest
include middleware technologies, enterprise-wide systems, database technologies,
application development, network management, security, RFID technologies, and
project management. |
Rate this page
| |
