A description of the CBDI Service Architecture & Engineering (CBDI-SAETM) framework in terms of its origins, objectives, principles, rationale, process and components and a discussion around how a reference framework needs to evolve to support user requirements today and in the future. This article will be of interest to anyone that is struggling to bring order to chaos in all classes of architecture and delivery project. A self assessment questionnaire is included in Attachment 1.
Most projects and programs muddle their way through the architecture, solution delivery and governance processes because they have an inadequate reference framework governing who does what, when and how. Key design decisions are commonly delegated to individual developers, agile teams or offshore partners with little or no real governance exerted over the architectural integrity of the outcome.
Most organizations are outsourcing and or offshoring their delivery processes as a matter of policy. However, few have adequate management and governance processes in place and are probably incurring unacceptable risks.
Whilst architects commonly have architecture contracts, the relationship between enterprise architecture and solution delivery teams is frequently broken.
Industry frameworks (such as TOGAF, ITIL and COBIT) are widely read and used for education and skills development, but usage is generally superficial because they are typically too general or high level to be useful requiring huge effort to put into practice. Collectively the frameworks are inconsistent and conflicting and a nightmare to coordinate. There is growing opinion that investment in these frameworks is a good way to waste time and money.
Industry standards for reference models and SOA are a mess. When major vendors get together to publish reports to explain how conflicting standards are actually complementary, you know there's a problem.
Yet a reference framework is a critical capability. Without clarity on the way architecture and delivery projects undertake their activities, there will be a proliferation of practices that lead to at best, inconsistency across the enterprise with high integration costs, and at worst the strengthening of application and technology silos. In this article we discuss how the CBDI-SAE approach has evolved to provide a practical, complementary mechanism to enable the benefits of the de jure frameworks.
CBDI-SAE has its origins in work undertaken in the 1990s on component based development and that continued to evolve through the 2000s on service architecture. By 2006 we recognized that we had created the skeleton of a framework and decided to formalize that by creating a structure and repository.
Why CBDI-SAE? And not TOGAF, ITIL, COBIT or CMMI? And maybe that list answers the question. Architects and project/program managers are faced with a huge task of making sense of frameworks that are quite inconsistent, operate at different levels with radically different objectives. Each of the various frameworks has value in its own domain, but none of them address cross domain issues, nor do they generally provide the level of detail required by a busy professional that needs to get organized quickly and wants to avoid reinventing wheels.
The objectives of CBDI-SAE are therefore not to deliver a fully comprehensive framework that in any way competes with the above list. Rather CBDI-SAE is a set of resources within a structure that spans a much broader space with clearly stated objectives to support architecture and process improvement in specific classes of project and program. CBDI-SAE provides:
Continued in PDF...
A description of the CBDI Service Architecture & Engineering framework for SOA in terms of its origins, objectives, principles, rationale, process and components and a discussion around how a reference framework needs to evolve to support user requirements today and in the future.
File Size: 842KB
Published: 15 Dec 2016 12:16