As many folks know, my gig at PSGroup is a combination of architectural consulting and industry analysis. While my architectural background is typically present in all of my work (for good and bad), some weeks it pushes to the forefront. This was definitely the case in late September and early October. During that period I wrote two reports on solving classic/big IT problems using service-orientation (architectural style), a supporting enterprise SOA environment, and architectural, development and project management discipline.
Parallel Universes
The first report, Thinking About Oracle’s Application Challenges, (free with registration) was written immediately after Oracle, the serial merger, announced its intent to buy Siebel (on top of PeopleSoft, JD Edwards, Retek and ProfitLogic). I don’t know about you, but when I hear merger, I think integration.
When I was writing that report, I was answering the following question “What would I do, if I were Oracle’s application portfolio architect?” (Run!) What’s the relevance for enterprise IT? The underlying question is really “How can
you keep a large, redundant, entrenched, heterogeneous portfolio alive and responsive to the business, while building for the future?” This is the “parallel universe” problem. The Oracle situation makes a great discussion backdrop.
I’ll share the core of that paper – an abridged problem setup, the strategy, and architectural plan activities – in this post. But first, cake…
Non-Invasive Application Package Customization
The second report, The Vanilla Layer Cake Theory – Using Service-Orientation for Non-Invasive Application Package Integration, is a theory I’ve been toying with/shopping around for a long time. The set up for the report is as follows:
There are classic rules of thumb used in buy/build decisions. Buy in situations of parity. Build for competitive advantage/differentiation. In a buy scenario, you willingly cede control of the end product (functionality, architecture, technology) for the promise of a lower price tag, ease of implementation, and quicker time to market. For success, you must actually cede that control—in other words, no modifications. But, that’s not always realistic. So, how can you reap the advantages of a buy, while providing a solution that actually fits your business (modifications and extensions), without getting trapped? Think Vanilla Layer Cake.
The Vanilla Layer Cake Theory – Quickly
The vanilla layer cake theory is simple. Do vanilla (out-of-the-box) installations of all new application packages. Then, customize and extend the application functionality using abstraction layers, rather than in the application package itself.
Vanilla Layer Cake Illustration.
In essence, the application package installation performs the role of a provider in a service-oriented architecture. In some ways, the application package is more valuable for its building blocks, than how the vendor assembled it.
The abstraction layers implement your business architecture, in the form of an enterprise information model, business services, business scenario composition (process, events, service orchestration), and user interaction (portal, user interface, unified in-box).
If this sounds familiar with my previous writing and advice, that’s intentional. I believe there are fundamental architectural constructs (and implementations), such as service orientation, composition and choreography, and unified information models that can be applied to a variety of IT problems. Thus, my enterprise architecture focus.
To see the theory in more detail, check out the report in its entirety on ebizQ. Let me (email, comment here, or article talkback) know what you think – other than the article leads with a picture of chocolate (vanilla icing) cake.
THE PARALLEL UNIVERSES EXCERPT
Merger Driven Integration Challenges
When enterprises merge, you often end up with duplicate enterprise applications (ERP, financials, human resources, and/or customer relationship management) and databases (customer, product, inventory, order, sales history, and employee), on a multitude of technologies, with inconsistent business rules and semantics (terminology, meaning, and format). The first pass of integration work as a result of merger is geared towards visibility and survival.
Typically, enterprises pursue federation strategies for the short term. Leaving information and applications in place, and providing new mechanisms (spreadsheets, queries, extracts, portals, data hubs, and/or composite applications) to access the systems of both companies, and present the information in a unified view.
For the longer term, enterprises pursue consolidation strategies, picking the best of the redundant systems and establishing migration initiatives to move people, processes, and information to the chosen solutions, while eliminating the redundant systems from the portfolio. This is hard work, and often takes precedence over IT initiatives focused on new business opportunity. Unless you have exceptional architectural planning and project release management, it is difficult to add (and deliver) new features to a moving target.
Software Vendor Merger
As difficult as mergers are for enterprise IT, consider the case when applications are your product, and you work for a serial merger, such as Oracle. In the 2005 calendar year, Oracle has added PeopleSoft, JD Edwards, Retek, ProfitLogic and, most recently, Siebel applications, to its own application portfolio. A quick counting shows four customer relationship management applications, three human capital management applications, three supply chain management applications, four financial applications, and three order management applications. Not to mention, a variety of supporting databases, applications, and technology platforms.
In the enterprise, the natural course of action would be to drop applications from the portfolio. But for a solution provider, the rules of merger-induced integration are different. Vendors (who want to win new customers and retain existing ones) must devise architecture and implementation strategies that attend to existing product portfolios, while simultaneously developing a target portfolio. In addition, there must be a technical migration path from here to there. This is no small task.
Parallel Universes – The Strategy
How can you keep a large, redundant, entrenched, heterogeneous portfolio alive and responsive to the business, while building for the future?
- The go-forward application portfolio should be services-based, and product offerings should be assemblies (compositions) of services, business processes, events, and user interfaces, packaged by industry, and configurable by end customers.
- For incremental gains (refresh, new features, migration), services and data stores developed for the go-forward application should be injected into the existing applications.
- To facilitate interactions across domains and/or redundant systems, the existing applications should have access to a common integration mechanism.
- Since no one can afford to start from scratch, the existing applications can be mined for assets that serve as providers in the go-forward portfolio.
Parallel Universe – Illustration C – Used Throughout Next Section
.
Parallel Universes – Architectural Plan Activities
How to start? Here are seven activities to include on an architectural plan to attack the parallel universe problem, using a service-oriented strategy. These activities will not produce detailed project plans and portfolio asset designs, but rather
establish an architectural game plan for your portfolio. With the game plan in place, you can define and execute project initiatives to actualize your vision.
As with most architectural endeavors, there is iteration between the activities, and the activities don’t necessitate linear execution. It all depends on the specific problem, and the participants’ knowledge of the problem and solution domains.
As you’ll see, each activity is a large undertaking, some, such as remediation, actually spawn several initiatives. This is not a detailed architectural project plan, but a frame for architects to think about and plan their own work.
1. Take Inventory
No surprise: first you need to understand what you are dealing with. Depending on the inventory takers’ familiarity with the subject matter, and the availability and accuracy of documentation, this may be a quick task, or an arduous one. Since the inventory feeds (directly or indirectly) all subsequent activities, there is a fair amount of supporting detail. Your inventory should include:
•Functional Perspective––What are the base features and functions provided by each application? What are the industry-specific features and functions, and their relationship to base functions (child, interface, configuration, no relationship)? Include business-oriented functionality (open customer account, weekly sales report), user interaction-oriented functionality (email, subscription, print), and system-oriented functionality (error handling, application monitoring, notification).
•Information Perspective––What information is being contained, managed, processed, and exchanged by the application? Artifacts include data models, schemas, semantics (terms, meaning, and structure) and taxonomies. Include both business and metadata.
•Data Architecture––How is the application’s business data implemented? Are there separate data structures for operational, analytic, and integration data? How is information moved within the application? How is information accessed? What is the metadata architecture?
•Application Architecture––What is the application style (distributed, SOA, client server)? What are the major components? How do those components interact? What languages are the components developed in? What is the application security model?
•Infrastructure––What is the application’s deployment environment (application servers, Web servers, DBMS, O/S)? How are quality of service (QOS) and quality of protection (QOP) ensured? While QOS and QOP are always important, for this exercise, your interest is to understand any implications for activity 5––determine remediation options––ties to integration mechanisms (next).
•Integration Mechanisms––How can this application integrate with external applications, services, and data stores? Are there hooks at the user interface? Can external services be invoked? Does this application expose services? Can information be exchanged (send/receive) in real-time? This inventory item will feed into activity 5––determine remediation options.
•Product/Application Plans––What fixes, upgrades and/or enhancements are scheduled for this product/application? What customers (internal or external) are scheduled for delivery?
•Sales Pipeline/Life Stage––For software vendors, what is the pipeline for this application? What is the install base? For enterprises, at what life stage (new, stable/core, fragile/core, sunset) is this application?
2. Define/Model Business Architecture of the Target Portfolio
Next, you need to define and elucidate the business architecture of your target portfolio. Similar to the inventory, this is a typical IT activity. However, from this point on, you need to stop thinking applications with hard bounds, and start thinking portfolio, assets, and assembly. Remember, your end game goal is to define a collection of assets (services, information) which can be assembled into various compositions to fulfill business interactions (sales, merchandising, marketing, finance) for a particular industry context(s) (high tech, manufacturing, financial services, retail).
To identify the correct assets (services, information) and compositions, you need to perform degrees of business modeling, data modeling (schema definition), service definition and scenario (composition, choreography, orchestration) modeling. Don’t produce implementation schematics. But, don’t leave this step until you understand the business problem(s) you are trying to solve.
3. Articulate Target Architecture
The key assumption is the target architecture has a service-oriented style, but saying service-oriented doesn’t count as articulating the architecture. You need to think through the different architectural layers (user interaction, choreography and composition, services (business and infrastructure services), integration, information, application providers, application infrastructure, platform infrastructure), how each is defined, organized, implemented, and how it interacts with other layers.
In addition, you need to consider quality of protection, and quality of service. If you are a software vendor, or a large enterprise with multiple channels, lines of business and global presences, you also want to consider configuration layers for industries, channels and/or globalization.
Remember, this is the target architecture for a portfolio. You don’t have to build it out all at once. You might start small, user interface, service layer, information architecture and database, application server, and optional enterprise service bus (orchestration, integration). However, you should plan for all layers, so you can safely extend your architecture.
For the parallel universe, you need to define (and eventually deliver) your service layer, and information architecture. You want to build services for the target architecture, and then retrofit those (using integration techniques) into the existing applications. Same goes for the information architecture. Optimally, you want to leverage a clean unified schema and database implementation, and retrofit that into the existing applications. How you retrofit is determined in activity 5––determine remediation options.
4. Rationalize Inventory and Domain
In rationalization, you are evaluating your inventory (activity 1) against your business architecture (activity 2). Your objective is to find building blocks for the go-forward portfolio and refurbishments for the existing applications. The rationalization is driven from the inventory’s functional and information perspectives, and is supported by the inventory information collected on the data architecture, application architecture and infrastructure.
To start, you need to determine if an inventory item’s features (job) are required in the go-forward business architecture. If so, you need to look across all like assets (from the redundant applications) to determine which asset is the best building block candidate for the target portfolio. “Best” is not always clear cut. Application 1 may offer the nicest features and user experience in opening a customer account, but application 2 may have a more efficient technical implementation. In that instance, you may want to take the best of each, and create new assets. In addition to finding the best, you also want to identify the bad, assets that have poor implementations or limited functionality. You’ll consider replacing these with the new asset. In Illustration C, I use the colors red (replace), yellow (mining source), and green (good/replaced) to represent the rationalized inventory, and an ongoing transition.
Next, you want to take a look at scenarios identified in the business architecture that aren’t fulfilled by the current applications. If the existing applications have the majority of the functionality, but not the ability to interact, sketch out an integration scenario to capture integration requirements.
5. Determine Remediation Options AND 6. Establish Transition Strategy/Factory
The remediation and transition activities are inexorably linked. Before describing the activities, it is important to point out a classic integration pattern––canonical data model. In that pattern, you have one core standard representation of data. Let’s call it A. All data in the enterprise is translated to A’s representation. If you receive data in format B, then you translate it to A. If you receive data in format B, that is destined for a third format (C), you still do translations based on A. B to A to C.
This pattern applies to the parallel universe strategy. The canonical format (so to speak) of services, orchestrations, and information schemas is determined by the target architecture. We mine raw building blocks from the existing applications and refurbish them to the target architecture (“to be”) format. To utilize those resources (building blocks) back in the existing applications, they go through a transformation (interface) that works with that application’s integration mechanisms. This is shown in the center of the Illustration C, in the Transition Factory. While this seems like extra work, it allows for the same underlying resource (code, information) to be utilized in all applications, across universes.
Determine Remediation Options. In this activity, your objective is to determine how each existing application can utilize resources of the target portfolio, natively, or with interfaces. The resources may be services (new, or the result
of mining/refurbishing), compositions/orchestrations, information sources (the unified model), user interface, or application infrastructure. In remediation you aren’t applying the resources, but preparing the applications to be integration
ready.
How you remediate, and how much, depends on your situation. If you are Oracle, then the remediation could be fairly significant. It wants to move to a common code base and information model to facilitate its customers’ inevitable migration to the target architecture. However, the infrastructure changes need to be minimal, because customers won’t rip and replace. For Oracle, it would be important to explore Java-based integration solutions, which can run in a J2EE container.
If you are an enterprise, and you are working with packaged applications, then you want to pursue a non-invasive integration strategy. Review your integration mechanisms inventory, and see what hooks (user interface, API, Web Service, messaging, database calls, file import/export) are available to you. If you are an enterprise and dealing with your own applications, then you should determine how to service enable (expose and invoke) your application. As well, explore options for database redirection (using views, federation technology, and data movement strategies).
Beyond the individual application remediation strategies, you also need to determine your inter-application integration strategy. Depending on your requirements, this integration solution may serve double duty, facilitating interaction between the existing applications and acting as a remediation helper.
Establish Transition Strategy/Factory. Based on your integration mechanisms, remediation decisions and target architecture, you need to establish the procedures and environment to transform building blocks from raw mined form to target architecture form, and target architecture form (new or mined) to integration-capable forms.
7. Formulate Release Management Strategy
Lastly, but certainly not least, you need to formulate a release management strategy that coordinates the initiatives to build out the target architecture and portfolio, remediate the old, and mine, transition, and apply resources. The release management strategy is more than a “plan of plans”; it needs to include mechanisms for communication, prioritization, re-prioritization, conflict mediation, contingencies, risk management, and status and issue tracking.
