Enterprise Integration Maturity Levels

In the previous posts, we have defined the key concepts of:

• Enterprise Transformation
• Enterprise Standardization
• SOA Design Principles

Today we're going to explore a related topic - Enterprise Integration. Integration is involved to some extent in all of the above listed topics. We will first review some guiding principles for integration and then provide a high level descriptions for integration maturity levels. 

Integration Principles

Enterprise Integration Maturity Levels

Legacy Integration Level
This level represents organizations transforming from a silo maturity level. In these situations integration is tightly coupled and usually not comprehensive. Even still the legacy integration maturity level generally reduces operational and maintenance costs while enhancing capability. These cost reductions are realized by reducing redundant and laborious data entry processes and reducing batch cycles to transform and transfer the data from one system to another. From this transition the data is available on a with reliable delivery of data and automated data format conversion for the integrating systems. The transformation from structured programs to all modular also leverages re-usability of the code and help and re-usability and reduction of the software maintenance complexity since the software is more modular. The modular code increases readability of the code best reducing maintenance time.

Componentized Level
Organizations transforming from an integrated maturity level to componentized maturity level  benefit in preparing themselves to expose business functionality at more granular levels. The re-usability also matures to a business function level as compared to an application level. Enhancements and new functionality are achieved through re-factoring in existing applications into smaller reusable components. The dis-aggregation of the business logic in itself helps in reducing the complexities of systems and facilitates the analysis of the impact of componentized solution on new business models and business transformations. This componentization also helps the business in reducing the time to market and increases IT response to business changes.

Shared Consolidated Infrastructure Level
This involves the deliberate unification / consolidation of Data Center capabilities including:

• Shared Hosting
• Virtualization 
• Process Integration (ITIL)

Service Level
The transformation from a componentized maturity level to a service maturity level evolves the organization into a service provider. The service provider role can serve other organizations within the enterprise as well as external organizations. Business services now become reusable as this maturity level reduces the need for redeveloping the same functionality for multiple systems by the provision of reusable business services called through a standardized interface irrespective of the technology platform on which the application is running. These business services can also offer access to data in a controlled timely manner which reduces inconsistencies in the data within systems that access and update the data. The investment of effort in service identification, specification, development, testing and implementation is paid back when new systems require the same service from the providing organization since the cost of infrastructure and maintenance of common functionality is reduced.

Composite Service Level
Organizations transforming from the Service maturity level to Composite Service maturity level have structured their business and IT support so that new business processes may be more rapidly constructed out of business services and provide new business functionality to different parts of the organization more efficiently. This maturity level is also associated with reduction of the time to market for new business models or capabilities. At this level transformation it is primarily a re-composition of the business services provided by different organizations within an enterprise of the value chain in the enterprise.

Software as a Service (SAAS) Level (Cloud)
Software as a service is the next logical maturity level. SAAS builds upon the shared (Cloud-based) infrastructure and shared enterprise capabilities developed in the previous maturity faces. SAAS allows organizations to provide capability as a commodity which either enhances existing revenue generation functions or creates new ones. In addition, systems may be reconfigured to achieve higher reliability without the consumers having to modify their code. Software as a Service enables organizations to better align business requirements with IT capabilities by building robust services that are highly flexible, manageable and scalable.

Copyright 2012  - Technovation Talks, Semantech Inc.

Read More

Understanding Enterprise Standardization

Just last week, we introduced the concept of Enterprise Transformation. Enterprise Standardization is often considered to be a part of Transformation, with special attention usually being given to data and shared service and infrastructure standardization. We can think of Standardization efforts as being the tactical elements of any given Strategy or (umbrella) Transformation initiative. Transformation is more EA focused, while Standardization must necessarily grapple with issues at the project level.


The ability to develop, harness and manage enterprise business capability begins with the ability to standardize the design process and with it the solution architecture. Standardization encompasses a number of different tactical areas including, but not limited to:

• Business Process
• The Data itself
• Hardware / Infrastructure (this generally involves both process as well as data center consolidation)
• Network Management
• Application Lifecycle Management (ALM, this includes Agile)
• Business Rules
• Data Architecture
• Security
• Commercial Software (and COTS Lifecycle Management)

A shared services paradigm (based on SOA) usually traverses many of these areas and facilitates their integrated management within an Enterprise perspective. The idea here is that with all of the different design approaches available, there needs to be mechanisms in place to integrate them. (if you don’t or can’t integrate design approaches, how can you hope to integrate the solutions developed from them?)

Enterprise Transformation generally requires multiple Standardization efforts

We’ve alluded to the need for greater standardization both in the context of architecture / design as well as in solution management in order to support a wider Transformation. Standardization is thus applicable at many levels. In particular, standardization provides a mechanism to help move from IT silos to unified Enterprise solutions. In that sense it becomes both a means and an end goal.
Specific decisions that lead to standardization include things such as:

• Adoption of standard software platforms. 
• Adoption of standard hardware platforms.
• Adoption of technical standards and best practices.
• Adoption of standard enterprise processes.
• De-conflicting of redundant logic, rules and systems.

Ultimately, the management of integration of heterogeneous IT environments and business models becomes the most expensive component of the business and the one most likely to add operational risk (w/o standardization). Thus, specific Standardization projects within a Transformation are likely to yield the highest return on investment - exactly which ones though hold the most value is usually determined on a case by case basis as every organization is somewhat unique.

Copyright 2012  - Technovation Talks, Semantech Inc.

Read More

Key SOA Design Principles

SOA primarily refers to a set of architectural principles. These principles represent a design continuum that links software development to Cloud deployment and capability exploitation. To support those principles a variety of standards and products have been developed to facilitate implementation and maintenance of SOA solutions. These standards include but are not limited to the following:

• SOAP - Simple Object Access Protocol
• UDDI - Universal Description, Discovery and Integration
• WSDL - Web service definition language
• WS Policy
• WS Security
• WS Addressing

The core SOA Use Cases are dependent upon its architectural principles

The design principles most often agreed to as representing SOA include the following (and yes some of these principles are inherited from Object Oriented Design or expand upon it):

• Standardized Service Contract – Services adhere to a communications agreement, as defined collectively by one or more service-description documents.

• Service Loose Coupling – Services maintain a relationship that minimizes dependencies and only requires that they maintain an awareness of each other.

• Service Abstraction – Beyond descriptions in the service contract, services hide logic from the outside world.

• Service Re-usability – Logic is divided into services with the intention of promoting reuse.

• Service Autonomy – Services have control over the logic they encapsulate.

• Service Statelessness - Services minimize resource consumption by deferring the management of state information when necessary

• Service Discoverability – Services are supplemented with communicative meta-data by which they can be effectively discovered and interpreted.

• Service Composability – Services are effective composition participants, regardless of the size and complexity of the composition.

• Service Encapsulation – Many services are consolidated for use under the SOA. Often such services were not planned to be under SOA.

The history, technical goals and expectations for SOA can be described thusly: “Service-oriented architecture (SOA) is an evolution of distributed computing based on the request/reply design paradigm for synchronous and asynchronous applications. An application's business logic or individual functions are modularized and presented as services for consumer/client applications. What's key to these services is their loosely coupled nature; i.e., the service interface is independent of the implementation. Application developers or system integrators can build applications by composing one or more services without knowing the services' underlying implementations.”

Copyright 2012  - Technovation Talks, Semantech Inc.

Read More

Demystifying Enterprise Architecture - Part 3

Part 3 – Utilizing EA as the Enterprise Interoperability Framework
We have thusfar explored how an EA can be used to help provide and identify a unification framework for the enterprise, how to use it to align all aspects of design but perhaps the most powerful application is as a facilitation mechanism for interoperability. A certain amount of that facilitation is de facto present once the first stages are undertaken. The ability to place all of the architecture information within a context in one’s own enterprise is the first step towards extending capability across multiple enterprises. To follow with our previous analogy with enterprise as organisms, the organisms must coexist to some extent within larger ecosystems. The interrelationships between entities determine the level of cooperation or collaboration that can take place. Those inter-relationships are built upon shared ‘cultural’ or cross cultural understanding.

The entire notion of ‘Services’ within a Service Oriented Architecture is more or less based upon this premise – capability structured through relationships on a ‘need to use’ basis rather than through assumption of need arranged by hierarchy. It is philosophical battle; deterministic logic pitted against the laissez faire availability of flexible pieces of an undefined puzzle. The philosophical view of SOA takes us one step close to expression of architecture as DNA. Within SOA, the term ‘loosely coupled’ points to another important consideration for architecture as interoperability mechanism – the fact that architecture elements or components are more effective when left flexible and in this the flexibility is engendered through abstraction. In the past, using deterministic logic, systems literally hard coded the relationships between data and application logic thereby linking them synergistically in a rather negative way. The interaction and impacts of large, highly controlled inter-relationships made maintenance difficult and eventually impossible across data and application layers. This led to multi-million line chunks of code and highly tangled data structures with little effective way to separate logic back out.

An example of using EA as an Enterprise Interoperability Framework

Our focus on SOA doesn’t mean that you have to adopt SOA per se in order to facilitate interoperability; in many ways SOA as a term or discipline is highly misleading or confusing as it means different things to different people. The principles we’re describing here are not attached to any point in time hype though, when the term SOA goes out of fashion, the following principles will remain.

• Interoperability is multi-directional, many-to-many in nature. Point to point or one to many paradigms have limited value.
• Interoperability depends upon abstraction, the levels or types of abstraction are basically unlimited – anything can be abstracted from anything else.
• Interoperability can be visualized and mapped (but this eventually must become reactionary rather than visionary as the level of complexity increases).
• Non-deterministic interoperability will result in lower complexity and reduced management overhead.
• Interoperability is relativistic – the universe of possible interaction is simply too much to imagine; it represents variability at the quantum level, so why fight it? There will be some basic rules governing environmental behavior, but these rules will be designed to allow for flexibility.  

Conclusion
What we’ve described above represents a somewhat radical departure from how enterprise architecture is currently viewed and practiced. To get from where we are now to this will require some time and thought as well as experimentation. However, the philosophical premises postulated here have the potential if implemented together to drastically transform the entire practice of IT. If anything is certain it is this – our technological progress is outstripping our ability to manage information. This is happening because we are still tied to the deterministic philosophies founded when resources, memory and scope was limited to a tiny sample of the potential virtual universe laying before us. Memory, scope and scale are now opening across a wide aperture – we’re viewing the infinite just beyond the horizon and lack the vocabulary to describe it.

Copyright 2012  - Technovation Talks, Semantech Inc.


7X6KFAEETJPC

Read More