Shawn P. McCarthy | 10 steps toward solid government SOA
Connecting state and local government leaders
Internaut'commentary: When it comes to SOA, the only way to go is bite-size chunks and a long-term plan.
Service oriented architecture is a long-term goal for many federal agencies. But the path is a long one: An agency that wishes to move to SOA needs an internal champion who can push for progress. Then, design decisions need to be made. A re-engineering of business flow, sometimes agencywide, is necessary, and you need buy-in at multiple levels.
Meanwhile, employees in the trenches need to understand that SOA is a concept for resource sharing, not a protocol unto itself. There is no single solution for implementing SOA. Competing sets of technologies, from open source to vendor-specific, can make an SOA architecture a reality. Yet any chosen solution needs a standardized framework allowing new services to be built, deployed, monitored and managed as the foundation of a flexible information technology infrastructure capable of addressing shifting government business demands
That's no small task. So where does an agency start?
1. Clarify your rational for SOA. You may not need it, but if you do, it's probably to align system resources with new or emerging business needs, allow your organization to leverage useful sets of services across multiple applications or eliminate multiple views of information across your enterprise. It also may help cut your overall operating costs.
2. Recruit SOA champions across your organization. Make sure each unit is represented on the team, not only to improve opportunities for buy-in but also to ensure that the evangelizing message of SOA trickles down to all IT managers.
3. Establish your governance structure. Be aware of existing SOA governance efforts within the government, such as the federal Chief Architects Forum and the CIO Council's Architecture and Infrastructure Committee.
4. Establish your technology for service delivery and composition and the management processes you will use to monitor them. You can be vendor specific or vendor neutral, but choose an architecture that will allow you to expand without locking into a single proprietary solution.
5. Consider funding issues. Very few agencies will fund agencywide SOA projects. Most will start with smaller projects, such as the $6.2 million series of biometrics projects at the Homeland Security Department's Citizenship and Immigration Services directorate or the National Oceanic and Atmospheric Administration's $2.6 million Global Earth Observation Integrated Data Environment. These are excellent potential proof-of-concept efforts that will also help apply an agency's enterprise architecture to future SOA expansion.
6. Consider SOA a series of iterative improvements, not a single, enterprisewide project. Build your initial SOA with just a couple of services in mind, and get them up and running reliably.
7. Start small. Your first effort will offer many lessons that will make it easier to expand to other services. This initial environment will become the foundation for future enterprise expansion.
8. Look for hidden service gains. The real win for SOA may come from the way you interact with services vendors. If a vendor offers a good IT service solution, you can connect your network of individual applications to that service. You then pay for the use of the service, but you don't have to help fund the development and implementation of that service.
9. Think about virtualization. Many agencies are moving toward system virtualization as a cost-savings effort. Be aware that virtualization can aid SOA and vice versa. Virtualization allows simulation of combined resources. This supports building multiple components into a virtual application and centralization of data tagging and sharing.
10. Be aware of the move toward government cloud computing. Cloud computing is a hot buzzword right now, and it's often touted by Google and other vendors. This type of computing, in theory, lets you worry about services, not the technologies used to connect to those services. They can be anywhere on the Internet, though you have to use trusted resources. The idea is to separate application code from physical resources and ' if desired ' relocate some of your infrastructure to lower-cost areas where, for example, property and electricity are cheaper. Delivered services over a trusted cloud may include application components and full applications, storage, processing power and access to specific resources.
Thinking through your agency's involvement in SOA ' from why you want to start to where you want to end up ' can help make your migration iterative with a series of well-managed steps and a solid enterprise SOA architecture.
NEXT STORY: OpenSolaris modernizes packaging