In my last blog about governance and the application lifecycle, I mentioned I would cover six reasons why Governance can solve sticky issues for IT attempting to modernize their applications and architecture. So let’s get to it.
Reason or Challenge #1: Visibility
You can’t modernize what you can’t find…
An IT enterprise architecture team chartered with application or architecture modernization will very quickly realize that agility increases consistent with complexity, or in more basic terms.. this modernization stuff is hard. Modern approaches, while powerful and agile, also come with a lot of moving parts. The team will quickly realize they must create a manageable, known “place” for all the information related to modern applications such as shared services, consumption relationships resulting from composition (building applications by composing them from existing services rather than by scratch) and underlying dependency metadata (requirements documentation, XML schemas, and more). This virtual place must also provide insight into where services and dependencies are in the lifecycle "not just what but who, when and how", and this place must allow the info to keep up with changes and allow seamless updating (no, a large paper filing cabinet or giant binder isn’t going to cut it anymore) 
Once IT commits to a modern architectural approach and their projects move from having one-to-one mappings between project definitions, requirements and purpose-built applications to the one-to-n mappings between projects defining composite applications assembled from shared services, full visibility to data needed to manage the services and artifacts through the lifecycle is critical to keep the project moving forward especially when handoffs are involved (can we say hand off from dev to test?). The risk of key information being "lost in translation" can cause the moving parts to come screeching to a halt. Modern composite applications equal many moving parts, many people involved, and many dependencies. It’s no longer going to cut it by managing all the moving parts using spreadsheets, e-mail and cell phones.
The developer building the composition must find the potential shared services they will re-use so that they don’t build a duplicate service. And, they must have visibility to the technical and business requirements that come with re-using a service—so there are no surprises (such as when they have to move to a new version of the shared service). QA must know what combination of services and policies should be tested together to validate the functional, performance and security requirements of the composite application. The operations teams must know the recommended deployment stack targeted for a service to meet SLA goals and be able to provision without guess work the run-time infrastructure to ensure SLAs are met.
This key information about a service, its requirements, dependencies, consumption expectations and resultant compositions needs to be easily accessible to those who need to know at each stage of the lifecycle. Moving to modern application architecture means providing the right information with the right people at the right time in a form they can use.
This is a new capability typically not found in traditional portfolio planning, application development, testing or management tools. Come to think about it, it sounds a lot like the capability found in SOA Governance solutions – applied to the broader concept of modern applications and their lifecycles.
Up next, challenge #2 Aligning projects with services
Posted
03-24-2009 11:21 PM
by
kellyemo