elemental links

InfoWorld SOA Exec Forum: Key Takeaways from Enterprise (Real) SOA Practitioners

Earlier this month, I had the opportunity to attend InfoWorld’s SOA Executive Forum in New York.  The SOA Executive Forum brings together enterprise SOA practitioners and contemplators, SOA industry experts, and leading SOA practice and infrastructure vendors. Through formal presentations, real-world case studies, panel discussions, a solution showcase, and table and hallway conversations, enterprise business and technology professionals learn about SOA­­––the opportunities, risks, architecture, technologies, products and practices––in order to define, or refine, their own SOA strategy.

While the forum is vendor sponsored––by BEA, HP, IBM, Intel, SOA Leaders, Cisco, Infravio, InterSystems, Layer7, and SOA Software––there was a good balance of enterprise and vendor presentations, and even some mixed panels.

The enterprise presenters included individuals from organizations such as Merrill Lynch, Verizon, Sprint-Nextel, Guardian Life Insurance Company of America, The Hartford, Ohio State University Medical Center, SABRE, Pfizer, the U.S. Army, and the District of Columbia. [Kudos to InfoWorld for recruiting a great, diverse lineup to demonstrate there is more than one way to realize SOA.]

One thing that was abundantly clear to me (and my table mates), is there is an obvious disparity between the architecture origins of SOA, and the marketing messages of SOA infrastructure providers, who claim the answer to SOA is in infrastructure (registry, repository, Web Services infrastructure, SOA fabric and/or enterprise service bus).

Those of us who have pursued SOA in the enterprise know that SOA is an architectural strategy, enabled by products, but not centered on them. As Martin Brodbeck, Pfizer’s director of Global Application Architecture, stated in a session: “SOA is a loosely-coupled architectural strategy, and needs to be both technology and vendor independent.” 

The enterprise participation and perspective is what drew me to the event. Because the best way to learn what real people are doing, is to actually go talk to them! 

Last week, I published a (free with registration) report - Best Practices, Lessons Learned, and Takeaways from Enterprise SOA Practitioners - through the PSGroup Research Service based on content (presentations and conversations) from the SOA Exec Forum.  

In this post, I excerpt some key takeaways – all from enterprise practitioners. Before I list the takeaways, let me share my report’s closing thoughts, because I think they are important:  

The enterprise presentations proved that SOA is real. Enterprises are using SOA to provide both agility and productivity for business and IT. The secret is to approach SOA as an architectural strategy. In such, make decisions based on your business, technology portfolios, and people. 

Don’t be misled by vendors who claim SOA can be bought in a box. Don’t be misled by technology snobs who claim SOA is Web Services. Remember loose-coupling, well-defined interfaces, and standards based messages. 

If you have questions on your strategy, speak to a trusted technology- and vendor-neutral advisor, and network with other enterprises. For a healthy dose of reality, attend sessions like InfoWorld’s SOA Executive Forum. 

Excerpt: Takeaways from Enterprise SOA Practitioners 

1. How Is SOA Being Justified?

When justifying SOA, the presenters used the terms re-use, agility, and productivity as follows.
 
Re-Use. SOA purists speak to re-use solely in respect to the service itself. If you create a customer account service that three lines of business use, across three channels, then you have achieved significant re-use payback. Many vendors at the forum took this purist stance. 

The IT presenters at the SOA Forum also spoke to the re-use of the providing asset. So, if you create a customer account service, which allows you to extend a legacy application asset to the Web that counts as re-use. This is true even if only one Web application consumes that service. Presenters spoke to the value of “liberating existing data.” 

A variation of re-use is shared services. In a shared service situation, an organization creates a service for external use. Consumers of a shared service may be a customer, a partner, or in the case of Google, Amazon, and Yahoo!, the great unwashed.

Agility. On the business side, agility refers to the composable nature of services. If you can easily add, remove, augment, or tweak applications and processes––using services and metadata-driven business rules, orchestrations, and policies––then you can be extremely responsive to your business. 

On the IT side, agility often refers to provider layer. The loosely-coupled nature of services and providers allows for the non-invasive replacement of underlying providers, such as application packages, legacy code, and databases. 

Productivity. Obviously, there are IT productivity gains from re-use. A couple of the presenters also called out reduced maintenance costs, since a loosely coupled solution is easier to refresh, change, and extend over time.

However, the presenters cautioned the audience not to expect immediate productivity gains. In fact, the initial transition to SOA will cause a productivity decrease, as you build out an SOA environment and skills. 

2. The Architecture in SOA Is Enterprise Architecture

All too often, the industry hype portrays SOA as Web Services-based application development. In actuality, SOA is an architectural strategy––an enterprise architectural strategy––that relies on good architectural foundations for success. The enterprise presenters made this point very clear. Two architectural dependencies the majority of the presenters called out are:

Business Architecture. Services and compositions reflect your business architecture, not your existing application portfolio or code base. You need to understand your business domains, functions, rules, processes, interactions, offers (products and services), and events in business terms. 

Information Architecture. If your information architecture is a mess, your SOA will be a mess. Every enterprise should have a canonical data model that is the definitive source of key data terms, definitions, and relationships. In a perfect world, this canonical model would be your implementation schematic. But, in the real world, the canonical model drives your semantic interpretation and data translation strategy, so services don’t just message each other, but communicate. 

Some presenters had adopted industry standard dialects, such as ACORD and XBRL, while others relied on in-house agreed-upon terms. The District of Columbia incorporated semantic Web technology, resource description framework (RDF), in its information definition and interpretation strategy.

3. Keys to Success in Your SOA Journey

The keys to success were amazingly consistent, from presenter to presenter. Not surprising, the overarching message was SOA is a journey. Success requires incremental pursuit and measurable business returns. 

SOA Strategy/Program Execution

• SOA = Architecture. Recognize that SOA is an enterprise architectural strategy, not merely an application development model. See above.

• Start Small. Pick a project that can have a measurable return, but poses no great business risk. First projects often connect the disconnected, or liberate information.

• Grow Organically. Encourage organic growth of SOA from one or two top development teams. Pick teams whose members are good technicians, want to follow standards, like to work smarter, and are influencers. Don’t start with an architectural mandate.

• Exploit Business Knowledge. Find an “uber business analyst” to be part of your long-term SOA competency center. This individual knows your business really well and has good enough knowledge of technology. This individual will facilitate the requisite service and business process definition, leading your organization away from business as usual to agility.

• Evangelize. Evangelize based on your initial successes. Spread SOA education to business partners and IT professionals.

• Govern. Establish governance and coordination mechanisms to optimize SOA. Share practices, services, and infrastructure. Coordinate service, project, and infrastructure development plans.

• Measure. Measure your results. Merrill Lynch includes re-use in a return on asset (ROA) measurement, and agility (time to market gains) in a return on investment (ROI) measurement.

Technical Execution

• Create a Strong Service Catalog. Define your services in business terms. Create course-grained services from compositions of fine-grained services.

• Communicate Your Service Catalog. Establish a repository that is the “trusted place to go” for service descriptions, interfaces, bindings and policies. The repository could be as simple as a spreadsheet, or a Wiki, or a commercial repository solution.

• Start Simple. Initial services are typically stateless and fine grained. With simple services in place, compose larger-grained, stateless services. Then, proceed to large-grained, stateful services.

• Common Practice. Services are “discovered” at design time, not runtime. During design, developers learn of a customer account service, and the interface and invocation requirements. Enterprises are not dynamically discovering and invoking services at runtime.

• Best Practice. From the onset, leverage mediation techniques. Mediators sit in between requesters and services. Use mediation to abstract common, crosscutting functionality, such as logging, security and protocol transaction out of your services.

Typically, mediation is performed by SOA and/or integration infrastructure. Examples mentioned in the presentations were SOA Fabric (Blue Titan), SOA Security Appliance (Reactivity, Layer7), enterprise service bus (Sonic, BEA’s AquaLogic) and EAI solution (WebSphere Message Broker).

• Be Standards Based. Be Smart. There was overwhelming agreement that standards are critical to service composition and communication, and infrastructure interoperability. Specific to services, the following themes emerged:

- XML and HTTP are the most important standards. All presenters incorporated XML in messaging.

- Web Services (SOAP and WSDL) are important, but not a requirement. For the sake of performance and ease of use, many implementers offer more than one technical implementation model for the same service. The models were Web Services, REST (XML/HTTP) style services, Java services, and .Net services.

- Of the advanced Web Service standards (WS-*), the most common implementations are WS-Security and BPEL.

- There was one example, from the Ohio State University Medical Center, that used a broad contingent of advanced Web Services standards, including WS-Security, WS-Policy, WS-Trust, WS-SecureConversation and WS-ReliableMessaging. The initial implementation used Microsoft’s WSE 2.0. The current implementation uses Microsoft’s Indigo.

•  Abstract Complexity. Leverage tooling and frameworks to abstract technical complexity away from developers and assemblers. This complexity includes standards implementations, technical mediation, and resource integration.

• Remember Human Element. Don’t forget the human element of SOA. People interact with services, business processes, and events through portals, rich interfaces, and subscriptions (RSS), across a range of devices: PC/browser, handhelds, and pagers.

4. Warnings and Lessons Learned

Although the presenters are successful advocates for SOA, they each faced challenges along the way. Here are some warnings and lessons learned.

Be Prepared For:

• Business Executive Skepticism. Business executives still have scars from previous IT paradigm shifts. Be prepared to face resistance. Instead of arming yourself with slides and marketure, bring tangible results. Implement a small services project—perhaps just one service connecting previous disconnected channels or domains, and share the results. Explain how SOA is a foundation, and incremental investment brings incremental gains.

• Development Community Backlash. Developers often rebel against the perceived restrictiveness of standards, and the not-invented-here (NIH) nature of services. To counteract this, educate that standards actually promote innovation. By not worrying about the “framing and plumbing,” developers can focus on the business problem at hand, and bring their creativity to bear for business advantage.

Regarding NIH syndrome, make your service developers “heroes.” As we’ve learned from open source, adoption (and acceptance) of a developer’s code, leads to community credibility and status.

• Business Community Pushback. Business agility, often through business process changes, threatens the norm, and jobs. Be sensitive to the implications. Collaborate with your business to facilitate business change; don’t define the business change from IT.

Don’t Underestimate:

• The Three C’s. SOA success requires communication, coordination, and cooperation within IT, across business units, and between IT and the business.

• Operations Impact. SOA is a hyper-distributed, horizontal architecture. Systems management and monitoring solutions are vertical or agent based. Production turnovers must contain a step to educate and hand-off to operations. Provide documentation and insight on the components (infrastructure, application, and data) and interactions required for your service-oriented business solution.

Keep in Mind:

• The SOA Readiness of Your IT Partners. Individuals working for systems integrators and development outsourcing shops do not have SOA training or experience. In outsourcing situations, you need to control the architecture and be very specific in your requirements. The output you will receive is exactly what you ask for!

• Business Process Outsourcing and SOA. If you are considering business process outsourcing (BPO), make sure your provider has an SOA strategy. If not, you will be locked out of agility, or find yourself in renegotiations.

5. Help Move the Industry Forward

The enterprise presenters had some requests of the audience to advance SOA, and more importantly, the promises of agility and productivity. I share those here, and encourage readers to help move the industry forward.

Push Your Vendors:

• Demand Service-Oriented Solutions from Your Software Vendors. An example cited was Siebel’s new Component Assembly offering.

• Demand Standards-Based Infrastructure Offerings from Your Vendors. In a service-oriented world, the infrastructure layer is also a loosely-coupled, business-driven composition. As stated by more than one presenter, “The best vendors make themselves replaceable.” 

Use Your Influence:

• Influence Standards Bodies through Your Vendor Partners. Articulate your requirements, but do not expend valuable time and resources sitting on standards committees.

• Influence College Curriculums to Teach Beyond Traditional Algorithms. The real world is composition, mix and match, and service oriented. If they balk, refer them to Ray Ozzie’s Internet Services Disruption memo. 

Solving Classic Problems Using SOA

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.