SOA Forcing A Shift In IT Governance
As more and more companies adopt a service oriented approach to developing and maintaining existing enterprise systems, IT governance also needs to shift its philosophies to fit the emerging development paradigm. When I first started programming companies placed an emphasis on “Code and Go” software development style. They only developed for current problems and did not really take a look at how the company could leverage some of the code we were developing across the entire enterprise system.
The concept of Service Oriented Architecture (SOA) has dramatically shifted how we develop enterprise software with emphasizing software processes as company assets. This has driven some to start developing new components as processes strictly for the possibility of future integration of existing and new systems. I personally like this new paradigm because it truly promotes code reusability.
However, most enterprise level IT governance polices were created prior to the introduction of SOA in their respected organization. This can create a sense of the Wild West for developers working on projects related to SOA. This is due to the fact that a lot of the standards and polices implemented by enterprise IT governing boards were initially for developing under the “Code and Go” paradigm and do not take in to account idiosyncrasies found in the SOA/integration based development.
As IT governance moves forward its focus should aim more for “Develop to Integrate” versus “Code and Go” philosophies.
Examples of “Develop to Integrate” Philosophy:
Defining preferred data transfer methodologies (XML vs. JSON), and when to use them
Updating security best practices for exposing public services based on existing standard security policies
Define when to use create new SOA project vs. implementing localized components that could be reused elsewhere in the enterprise.
