IT chump information technology and system administration

IT Strategies
Business Applications
Information Security
Systems Management


Data Center Operations

Our scope for information security includes protecting information systems and information assets from unauthorized access, use, disclosure, disruption, modification, or destruction. We follow the confidentiality, integrity and access (CIA) approach.

While our organization cannot afford a dedicated information security team, we do have two staff who focus exclusively on information security strategy, objectives, fulfillment and incident response.


As a global financial services company, we must be compliant with Gramm-Leach-Bliley Act (GLBA) and International Standards Organization (ISO 27001 certification) standards. We have three staff whom are members of FBI InfraGard and retain security clearances.

SOA Governance
Whether vendor achieves the above stated benefits has more to do with proactive polices and procedures than the quality of the code. For vendor to succeed with SOA, we must have an enforceable set of policies for building, deploying and managing services. vendor Governance uses guidelines and SOPs which are designed as schools, not prisons. The primary goal is to assist our staff to conform to the best practices while achieving palatable operational policies which produce consistency, predictability and allows big applications to be built from small pieces.

Gary will provide governance rules which specify interfaces, eliminate certain paths from consideration and delineate boundaries of acceptable behaviors. A primary architecture goal is to increase modularity and create well-defined abstractions based on service APIs. After these choices have been made, they must be documented, communicated and enforced.

In the same way that building codes, standards, and even inspections give building architects a context within which to work and ensure that their designs will fit in the community, SOA governance provides context for vendor developers. Without SOA governance, vendor will not achieve this technology’s benefits and we’ll end up in a Web services version of DLL hell. SOA governance must model staff behaviors and be woven into the fabric of our development operation.

[Gary] Development policy making efforts should begin with standards. After all, standards make SOA possible. For example, will WS-Security and WS-Policy be used? Under what circumstances will they be required?

You could call out specific standards in individual policies, but a better strategy may be to create an IF (interoperability framework). An IF is a special policy that lists the standards that our organization will use, points to reference information, and indicates the status of the choice: approved, de facto, emerging, sustained, sunset, or in process. Note that "Sustained" indicates that even though the organization has decided to support another standard in this area, use of the older standard is supported. "Sunset" indicates that developers should migrate from the standard as soon as practical. An IF separates references to quickly changing standards from individual policies, making them easier to manage.

The governance process creates policies, XML Schemas, WSDL documents, documentation, and other artifacts that must be distributed to Aplicor development staff. Registries are the primary tool organizations use for managing and communicating governance artifacts, as well as automating key governance activities. A registry provides a central reference or "system of record" for services.

Building codes would not be very effective at creating safe, pleasant cities if there were no building inspectors. Similarly, SOA policies aren't worth anything unless they're enforced. Some policies will be codified in WSM or development systems and can be enforced automatically. Others will be aimed at changing or regulating the behavior of our staff -- such as an edict that all services used in production-quality applications must be listed in a production registry -- and are less easily codified, let alone enforced automatically. Most important, recognize that SOA policy goals need to be aligned with financial incentives. Otherwise, service enablement will go on the back burner.

Enforcement requires closing the loop. When a service or process is found to be noncompliant, you need to take corrective action. On the other hand, noncompliance may also indicate that a policy is overly restrictive or poorly written. Ensure that your feedback process has pathways that lead to policy improvement. Also, no matter how carefully crafted the policy, developers are sure to run into situations where an exception to the policy would be in Aplicor's best interest. Make sure every policy has a route for raising and approving exceptions. Policies often name, by role, a policy owner who has spot authority to grant exceptions.

Because both Aplicor development and SOA are inherently decentralized, governance is the difference between development success and chaos.

Search | Links | Library | Rants | Raves | Site Map