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.
Recent Comments