Anatomy of Agile Enterprise

Post do blog http://www.ebizq.net!

==============
Anatomy of Agile Enterprise
Janne J. Korhonen

From Fragile to Agile: Enterprise Architecture Reform through BPM and SOA

user-pic
By Janne J. Korhonen on February 7, 2010 8:26 AM

Companies have invested vast amounts of money and effort in information systems. In the course of time, these systems have been integrated with idiosyncratic point-to-point solutions to address larger business transactions. While this has appeared as simple and practical on the outset, over time the increasing complexity has resulted in “integration spaghetti” that is prohibitively difficult and expensive to manage and maintain. The problem is aggravated by the increasing need for business agility that cannot be achieved with cast-in-concrete integration solutions.

 

While this deeply ingrained “technology mess” is too overwhelming to be dismantled and replaced, the truth is out there and can be disentangled. By mapping physical data to logical information objects and technical functions to business activities, a canonical information and operational model can be elicited. To this end, a business has to define its own, consistent ontology, which may partly be adopted from the normative nomenclature of its respective industry vertical. The data in the underlying information systems can be mapped to these canonical concepts using appropriate integration technologies and exposed as data centric SOA services. By analyzing the functional requirements of business processes, a set of logic centric services can also be identified.

In Service-Oriented Architecture (SOA), the intricacies of applications and technology infrastructure are encapsulated behind well-defined, self-describing service interfaces that expose the contained information and functionality as reusable, context-independent services. The underlying implementation of a service can be changed as long as the service contract is maintained. SOA services provide modular building blocks that can be composed to higher level constructs, e.g. orchestrations or composite applications. This coarse-grained modularity reduces the inherent complexity of the enterprise architecture and improves business agility. The service abstraction insulates business changes from IT development and thereby synchronizes the business and IT life-cycles.

In the following, I will attempt to outline how a “fragile” architecture, characterized by “technology mess” and “integration spaghetti”, could be reformed towards a more agile architecture through a concerted effort by business and IT, in which the business-driven top-down BPM (Business Process Management) meets the IT-driven bottom-up SOA. The stages can also be considered as architectural maturity levels.

  1. BPM: Review and specify the organization’s strategy. Describe the external context (position in the overall value configuration) and create a process map. Identify key business processes and specify their high-level key performance indicators (KPIs) and critical success factors (CSFs). This ensures that the global process performance is in line with the strategic objectives and provides the basis for more specific, accurate and correctly aligned objectives. SOA: Start the architecture reform within a pilot domain by replacing integration spaghetti with lasagna: route the idiosyncratic point-to-point integrations through Enterprise Application Integration (EAI) middleware. EAI approach simplifies application integration by providing a common integration backbone with routing and transformation capabilities. 
  2. BPM: Devise the process architecture that provides the foundation for the initial BPM initiative and all subsequent process management projects. Outline the process roles and sub-processes in the key processes. Choose one of these sub-processes in the same domain as the integration pilot and model the process in line with the process architecture guidelines. SOA: With the lessons learned from the pilot, expand EAI approach to the rest of the organization. Within the pilot domain, implement the first basic SOA services. The EAI tool can be used as the initial SOA platform. 
  3. BPM: Re-engineer the pilot process in sync with the SOA undertaking and start modeling other processes leveraging the experiences from the pilot exercise. SOA: Start implementing basic services in other domains. Automate selected parts of the pilot process by orchestrating implemented services to executable process flows. Also implement pertinent context-sensitive portal views to the workflow. As a result of this stage, one business process has been described and implemented top-down and bottom up, meeting in the middle, where services are bound to processes. 
  4. BPM: Once the business process is modeled and automated for relevant parts, it can be readily measured and continuously improved. Channel the business benefits of the pilot initiative to fund re-engineering other business processes in a similar vein. SOA: Expand service orchestration to new business process initiatives as needed. Build full-scale SOA infrastructure including Enterprise Service Bus (ESB), Registry and Repository, and SOA Management faculties. 
  5. BPM: When several domain-specific business processes have been subjected to Business Process Management, the “white space” between these processes can be considered. Whereas orchestration describes the control logic within a single process flow, choreography describes the coordination between these processes in the overall cross-domain end-to-end process. Deploy a full-fledged Business Process Management System (BPMS) to manage the choreography of collaborative, event-driven processes. SOA: Provide the improved capabilities to external partners as enterprise services and contract external services as needed.

It is important to think big, but start small; maintain a long-term grand vision, but realize it sustainably in incremental steps, learning from spearhead pilots, the success of which brings about confidence. Set the target level of maturity based on your business needs. Do not invest in top-notch infrastructure until you have reached the maturity level at which the technology is required. And do not try to jump over maturity levels. Slower is faster.

4 Respostas to “Anatomy of Agile Enterprise”

  1. asepsryn Says:

    I saw your article very good contribution to the presentation and can be responsibility, hopefully you stay ahead presents articles like this
    thanks for the article

  2. Wolfgang Friese Says:

    Dies ist ein Portal, wo Sie Ihre Domains und Webseiten kostenlos bewerten lassen können. Nur wir unterscheiden zwischen Domains mit www. und ohne. Dadurch können wir auch den Wert Ihrer Subdomains berechnen.
    Für die Berechnung des Wertes benutzen wir eine spezielle Formel, die unserer Meinung nach realistische Werte ermittelt. Wir wollen Sie nicht mit irgendwelchen Traum- oder Wunschwerten blenden, sondern Ihnen eine Hilfe für einen möglichen Kauf oder Verkauf sein.

  3. Pat Flanders Says:

    thanks for posting this…i saw it too. i like what Active Endpoints is doing – http://www.activevos.com – SOA is at the core of the product, but not a mission in and of itself.

  4. Africa Blog Says:

    Just want to say your article is as surprising. The clearness in your
    publish is just cool and that i could think you are a professional in this subject.
    Well along with your permission allow me to grasp your feed to stay updated with
    approaching post. Thanks 1,000,000 and please carry on the enjoyable work.

Deixe uma resposta

Preencha os seus dados abaixo ou clique em um ícone para log in:

Logotipo do WordPress.com

Você está comentando utilizando sua conta WordPress.com. Sair / Alterar )

Imagem do Twitter

Você está comentando utilizando sua conta Twitter. Sair / Alterar )

Foto do Facebook

Você está comentando utilizando sua conta Facebook. Sair / Alterar )

Foto do Google+

Você está comentando utilizando sua conta Google+. Sair / Alterar )

Conectando a %s


%d blogueiros gostam disto: