SOA Governance

SOA Governance1. Achieving quick successes is critical. It’s easy to get bogged down by the complexities of SOA architecture without much to show in terms of business benefits. Start with the needs of initial customers, get quick successes, and expand from there. The trick is to ensure baseline SOA architecture can meet requirements for future programs with minimal impact to previous implementation and not try to achieve world peace by figuring out requirements for all current and future needs of an organization.

2. Business alignment is a key to SOA success. There are too many companies with investments in SOA but not enough to show. For example, if strategic divestures is one of the key business goals for the year, then demonstrate how SOA team may come up with design patterns for business processes to allow for faster divestures compared to non-SOA implementation.

3. Organization Alignment – SOA can’t happen if departments continue to implement point to point interfaces. Any integration requirement must come to the “SOA team” which must then determine the best way to implement the integration (point to point may still be an option).

4. Canonicals or Enterprise Business Objects (EBO) – Choices include 1) using industry standards like RosettaNet, 2) your ERP vendor standard, or 3) going the custom way. Having a custom EBO may allow for a quick start with minimal effort and provides the flexibility to evolve as additional business requirements come up. However if you are already invested into a specific industry standard or vendor, then those options may be better than custom.

5. Prebuilt Integration Packs (PIP) – Vendors may upsell industry specific “integration packs” as pre-built process integration. These may allow for faster integration assuming your business process aligns with the PIP design. However following considerations may be important –
a. Compare the cost to build custom SOA interfaces with the cost (license + annual maintenance) of integration pack.
b. What is the learning curve involved to configure/customize the “integration pack” to your business requirements?
c. Is it feasible to configure/customize the integration pack to meet your business requirements?
d. Would you have to customize the integration pack resulting in a licensing or support impact?

6. Consider doing a POC (proof of concept) any time you have to integrate with a new system/technology to ensure that the adapters provided by the integration product vendor are compatible. Older versions of database like Sybase may not be supported and may require different integration architecture.

7. Technology decision criteria – You may end up with multiple integration products/technologies that overlap in functionality. Ideally, you should try to minimize the number of products for cost and ease of management. If you do need multiple products, there should be objective decision criteria for product selection.

8. Less is more – Technologies such as EAI, SOA, BPM, ETL etc all serve the purpose of integrating data and business processes across the enterprise. If the org structure is setup based on products/technologies then these different teams may compete with each other. Ideally there should be a single lead for all integration needs. However org structures are not always ideal and a faster solution may be to get consensus on technology decision criteria, as discussed above.

9. Strategy document – A strategy for business integration is really important. It’s a living document that can be key in bringing all stakeholders on the same page, document and explain key decisions, and avoid reinventing the wheel every time. It should have information on business goals & challenges, assumptions, analysis for products/technologies and decisions made, proposed architecture, solution considerations, reusable components etc.

10. Quality – Evaluate deliverables against a checklist to ensure consistent quality. This can be implemented to evaluate deliverables across the software lifecycle including requirements, design, code, testing, and migration. You may implement this as a simple checklist or as a more comprehensive rating mechanism.

Please contact me if you would like to brainstorm SOA or see samples for Strategy document, Functional Specs, Design document, Technology Decision Criteria, Checklist, Quality Functional Document etc.

By Rohit Arora

 

Leave a comment

Your comment

*