We use cookies and other similar technologies (Cookies) to enhance your experience and to provide you with relevant content and ads. By using our website, you are agreeing to the use of Cookies. You can change your settings at any time. Cookie Policy.

Anatomy of Agile Enterprise

Janne J. Korhonen

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

user-pic
Vote 0 Votes

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.


Janne J. Korhonen provides insights into how information technology can be applied strategically to catalyze organizational change and responsiveness. Drawing from both theory and practice, he discusses agile enterprise and its governance.

Janne J. Korhonen

Janne J. Korhonen is an independent business and IT consultant,specializing in enterprise architecture, business process management,service-oriented architecture and pertinent governance models. He has over ten years of experience as an architect and consultant in a variety of extensive and mission-critical IT projects. With strong theoretical underpinnings, his consulting encompasses systemic co-development of business, organization and information technology.

Recently Commented On

Recent Webinars

    Monthly Archives

    Blogs

    ADVERTISEMENT