(prompted by Enhancing the EA with SOA - by CBDIforum)
SUMMARY
Enterprise architecture is a slowly maturing practice used in an increasing number of organisations, as a valuable tool, not just from a technology perspective but also in terms of understanding how the business operates and what determines its operations (regulations, strategies, market factors etc.). Service Oriented Architecture (SOA) is being put forward as an approach for organizing systems and technology infrastructure architectures to better enable business agility. It is going to be critical that best practice in EA is extended to incorporate SOA perspectives.
This is precisely the area RHE has targeted through a focus on both EA (tools and methods) and on SOA (enabling technologies and methods).
DETAILS
For large organisations architectural complexity has become so great that the adoption of new technologies is a costly, high-risk, and time-consuming endeavor with legacy solutions often lingering for years after newer technologies are adopted. For many organizations agility enables new technologies to be exploited to create a competitive advantage in the market place. EA techniques are widely used to address this complexity, and to facilitate better decision making.
SOA is seen as one of the key enablers of business agility and its widespread adoption throughout the IT product vendor space necessitates that organizations learn to manage and exploit SOA. Everyone from new internet oriented organisationss (e.g. Google and a pethlora of other SaaS vendors) to the old legacy ERP vendors (e.g. SAP, Oracle) have adopted SOA as the primary paradigm for systems integration. Business organizations will rely more heavily on sets of third part products and services integrated to create their unique solution set (rather than large bespoke applications).
To capitalize on new technologies and products, organizations will need to mature their SOA capability so they can effectively integrate these packaged services to transparently support their business operations. This means incorporating SOA into their EA planning process.
There is also a more urgent driver for incorporating service architecture into the enterprise architecture. All of the main development environments today can rapidly publish .Net or Java classes as a Web service. The implication of this is that your organizations service architecture may be defined at the whim of any developer or software designer. And while a few may be professionals making good design decisions, very few, if any, have the enterprise perspective to identify the optimal collection of services for the enterprise without a broad planning process.
The EA must provide the target service portfolio plan that enables all these developers and architects to concurrently and semi-autonomously drive the software for which they are responsible toward a common strategic vision.
For many organizations, EA provides the first enterprise view of the systems architecture and the results are often enlightening. System redundancies and over-extensions become readily visible as do some cross-departmental value chain inefficiencies. As EA exposes these opportunities for improvement, organizations begin to analyze how to capitalize on them. This is where SOA comes into play.
Inevitably, the solution to these problems requires the containment and elimination of some technology solutions, while others are being extended to support a broader scope of use within the organization. SOA provides the means (formal techniques, best practices, and work products) that enable these problems to be solved and communicated with new clarity of purpose.
Software architecture tools also play a role here in allowing views of the major modules of applications and interactions between these modules to be understood. The modules and interactions may useful insights into redunancies across the applications portfolio and possible integration points which may be candidates for externalised services.
The transition process RHE has long recommended is to contain, through encapsulation (via introduction of a technology capability service), a technology targeted for retirement. This allows the business requirements to be aggregated on this service and facilitates the selection and downstream adoption of a newer technology. Once all dependencies on the older technology have been moved to the newer one, the older technology can be retired. Such a transition approach is inherently service oriented.
The CBDI item goes on to describe Zachman's framework and suggests most EA activities focus on the top three rows (where as I see very little if any focus on the top two rows - and most of the focus has historically been on existing infrastructures, applications and technologies standards (i.e. as far away from the business as possible). It then goes on to say that "these architectures are all similar from the perspective that they specify particular views" - which is clearly not really the case - as Roger Sessions has pointed they are actually not even of the same class i.e. TOGAF does not define a taxonomy, Zachman does (but the exact views and not that clear), FEAF defines meta-views (but is imprecise on what specific views might be), and it focuses on Reference Models (which are useful categories for investment planning and business cases), and only DODAF really focuses on views.
Most glaring they fail to define a key failing from the Zachman taxonomy defined 20 years ago i.e. that it doesn't really define interfaces (user or system) very well - because in what was essentially the "single mainframe, single application, terminal based access for an internal audience" model of 1987 these things didn't warrant much sufficient attention.
Table 2 suggests "Traditional EA Model Elements" include: Business Rule, Event - yet few EA's I have even seen have good organisation wide inventories of either. Good EA (if they were of the business) would also surely have a business's products/services, markets, projects/initiatives, locations etc.
The rest of the item is quite good in describing a services and how they should be modelled to allow them to be instantiated, used and operated.
This is precisely the area RHE has targeted through a focus on both EA (tools and methods) and on SOA (enabling technologies and methods).
DETAILS
For large organisations architectural complexity has become so great that the adoption of new technologies is a costly, high-risk, and time-consuming endeavor with legacy solutions often lingering for years after newer technologies are adopted. For many organizations agility enables new technologies to be exploited to create a competitive advantage in the market place. EA techniques are widely used to address this complexity, and to facilitate better decision making.
SOA is seen as one of the key enablers of business agility and its widespread adoption throughout the IT product vendor space necessitates that organizations learn to manage and exploit SOA. Everyone from new internet oriented organisationss (e.g. Google and a pethlora of other SaaS vendors) to the old legacy ERP vendors (e.g. SAP, Oracle) have adopted SOA as the primary paradigm for systems integration. Business organizations will rely more heavily on sets of third part products and services integrated to create their unique solution set (rather than large bespoke applications).
To capitalize on new technologies and products, organizations will need to mature their SOA capability so they can effectively integrate these packaged services to transparently support their business operations. This means incorporating SOA into their EA planning process.
There is also a more urgent driver for incorporating service architecture into the enterprise architecture. All of the main development environments today can rapidly publish .Net or Java classes as a Web service. The implication of this is that your organizations service architecture may be defined at the whim of any developer or software designer. And while a few may be professionals making good design decisions, very few, if any, have the enterprise perspective to identify the optimal collection of services for the enterprise without a broad planning process.
The EA must provide the target service portfolio plan that enables all these developers and architects to concurrently and semi-autonomously drive the software for which they are responsible toward a common strategic vision.
For many organizations, EA provides the first enterprise view of the systems architecture and the results are often enlightening. System redundancies and over-extensions become readily visible as do some cross-departmental value chain inefficiencies. As EA exposes these opportunities for improvement, organizations begin to analyze how to capitalize on them. This is where SOA comes into play.
Inevitably, the solution to these problems requires the containment and elimination of some technology solutions, while others are being extended to support a broader scope of use within the organization. SOA provides the means (formal techniques, best practices, and work products) that enable these problems to be solved and communicated with new clarity of purpose.
Software architecture tools also play a role here in allowing views of the major modules of applications and interactions between these modules to be understood. The modules and interactions may useful insights into redunancies across the applications portfolio and possible integration points which may be candidates for externalised services.
The transition process RHE has long recommended is to contain, through encapsulation (via introduction of a technology capability service), a technology targeted for retirement. This allows the business requirements to be aggregated on this service and facilitates the selection and downstream adoption of a newer technology. Once all dependencies on the older technology have been moved to the newer one, the older technology can be retired. Such a transition approach is inherently service oriented.
The CBDI item goes on to describe Zachman's framework and suggests most EA activities focus on the top three rows (where as I see very little if any focus on the top two rows - and most of the focus has historically been on existing infrastructures, applications and technologies standards (i.e. as far away from the business as possible). It then goes on to say that "these architectures are all similar from the perspective that they specify particular views" - which is clearly not really the case - as Roger Sessions has pointed they are actually not even of the same class i.e. TOGAF does not define a taxonomy, Zachman does (but the exact views and not that clear), FEAF defines meta-views (but is imprecise on what specific views might be), and it focuses on Reference Models (which are useful categories for investment planning and business cases), and only DODAF really focuses on views.
Most glaring they fail to define a key failing from the Zachman taxonomy defined 20 years ago i.e. that it doesn't really define interfaces (user or system) very well - because in what was essentially the "single mainframe, single application, terminal based access for an internal audience" model of 1987 these things didn't warrant much sufficient attention.
Table 2 suggests "Traditional EA Model Elements" include: Business Rule, Event - yet few EA's I have even seen have good organisation wide inventories of either. Good EA (if they were of the business) would also surely have a business's products/services, markets, projects/initiatives, locations etc.
The rest of the item is quite good in describing a services and how they should be modelled to allow them to be instantiated, used and operated.
