I recently participated as a panelist on this subject for Women in Technology. It kills me sometimes when us folks in IT are asked the question … how do we implement <insert technology du jour> in the enterprise? In preparing for the panel, I spent a little time preparing for that inevitable question.
First, let me define SOA – in plain language and not Geek-speak. It’s a way of developing software by grouping together software functions that perform loosely coupled services or activities. Examples of such activities might be online booking, guidance and navigation, or online application submission. NASA/Goddard Space Flight Center successfully utilizes this architecture in its GSFC Mission Services Evolution Center (GMSEC). The advantages are increased scalability, reusability, and flexibility in IT systems. This can result in better solutions at lower costs delivered faster compared to traditional development methods.
So, like I said, it kills me when CIOs are asked … how do we implement SOA in the enterprise? It’s the wrong question really. SOA for SOA’s sake is just plain stupid. The essential questions are strategic. What are the needs of your enterprise? What is your current state from a technology perspective? Can SOA do a better job of getting you where you want to go? Then finally, assuming the answer is yes … how? CIOs almost always look at three areas when thinking about the answers to a “how” question: People, processes, and technology.
People. The workforce needs to be trained to understand the suitability, value and benefits of this technology. It is often said if all you have is a hammer, the whole world looks like a nail. SOA is just one tool in the technologists’ tool belt. One must have more and discern when and how to use them.
Contractors who provide services to the organization must be incented to use this technology as appropriate. The typical “level-of-effort” contracts incent the behavior of 18-month software development cycle of monolithic systems. Contractors have to have incentives to utilize the right tools in their tool belt to deliver value and mission success to agencies.
There’s also a “not invented here” culture that may prefer to development home grown code rather than utilizing pre-existing code.
Processes. One big advantage of SOA is the ability to deliver cross-agency services. Governance talks about who makes decisions; when we make those decisions; what are the scope of things that are decided; how do we inform those decisions; and how do we make those decisions. But, how do we develop good processes or procedures for doing all that? Who has decision rights? How do we manage service levels? How do we perform release management and configuration management? What do we do if something breaks? Who is responsible for fixing it?
Technology. This could be one of the easiest areas assuming that governance is addressed adequately. We need to think about standards and we need an architectural framework that informs our strategy after synthesizing were we are as an enterprise, where we need to go, and what is the roadmap for getting there.
Yeah, SOA what! I like neat technology just like the next girl. It’s cool and snazzy, but if it is not solving a problem, we’re probably implementing technology that may not have mission value. The potential here is great, but first we have to pause and reflect on what particular problem we are trying to solve. And finally, we need to implement approaches that address the people, process, and technology dimensions.
Linda Cureton, CIO, NASA/Goddard Space Flight Center
