What CIOs Should Know About 'Outside-In' Architecture

Today's flexible, loosely coupled supply chains and business models require a whole new approach.

Eric Openshaw, Contributor

September 14, 2012

5 Min Read

Conventional wisdom can change as rapidly as the world around us. With information easily accessible and business processes transparent, standardizing processes, stockpiling resources, and trying to control operations is no longer sufficient. The capabilities that "add value" aren't necessarily classic manufacturing or service activities so much as those that connect capabilities across organizations. Innovation depends upon knowing how to connect.

Today, what organizations need is the capability to tap into third-party resources to meet changing demands and opportunities, and to adapt to changing players, rules, and desired outcomes. They need flexibility. That might mean the ability to offer services sourced from thousands of business partners, updated in real time, and maintained over the life of a transaction.

Rearden Commerce, for example, continuously adds multi-party travel and entertainment services for its corporate customers. At the same time, Rearden must support its customers' policies (geography, service class, cost) and resolve exceptions (rebooking, cancelation, delay) across the often-lengthy life of each transaction, from booking to fulfillment.

For many companies, flexibility also means the ability to change and customize offerings in response to external changes. For example, at TradeCard, a company that facilitates supply chain transactions, the financing requirements evolve rapidly based on global economic conditions, broader business policies, the changing payment terms of buyers and sellers, and new participants. TradeCard must not only track and mediate policies across buyers and sellers throughout the supply chain, but also identify profitable opportunities for the company to step in with new offers of financing, such as when a buyer wants to pay on a 45-day basis and the seller needs 30-day payment.

Each of these companies depends upon the ability to fulfill flexibly across many partners, sharing information and outcomes. They can't be worried about what system (or lack of system) each participant runs or waste time coding new interfaces or middleware to manage interactions. Conventional enterprise IT systems aren't very good at coordinating complex, long-lived transactions across multiple, autonomous parties, but that is just what emerging models based on collaboration and resource-sharing require.

[ To be the best, you have to be willing to hear the worst. Learn 6 Uncomfortable Questions IT Teams Should Ask. ]

In both cases, an "outside-in" architecture supports the more flexible, loosely coupled business model. TradeCard's outside-in architecture includes an emphasis on explicit management and mediation of policies across diverse participants.

Rearden Commerce created a virtual common policy platform, which is invoked by customers when searching for options based on geography, vendor preference, logistics, and expense policy constraints. It's used by merchants when listing, describing, and promoting their services. And it's used by Rearden to drive long-running transactions and resolve exceptions. Rather than build around business capabilities, Rearden links functional services to the underlying infrastructure stack. Policies encountered at the business layer drive actions at the hardware and network layers.

Global CIO Global CIOs: A Site Just For You Visit InformationWeek's Global CIO -- our online community and information resource for CIOs operating in the global economy.

The answer lies in re-envisioning your architecture, not as an enterprise-wide monolith but as interrelated systems and data sets, encapsulated for external consumption.

More Than Just SOA

Some of you might think this crossroads is starting to look familiar. Haven't IT departments been in pursuit of a service-oriented architecture (SOA) for years? Yes, but outside-in architecture is a more advanced concept. It exploits the shift from proprietary technical stacks to standards- and Web-based communication and interoperability. To accommodate a model where processes, systems, and even people are interchangeable building blocks, regardless of where they reside, can require a sophisticated platform of services to identify, provision, orchestrate, meter, bill, and mediate events across these components.

The implications aren't trivial. In an outside-in model, there's no guarantee of atomicity across systems and organizations. Failures must be addressed with compensating transactions rather than automatic rollback.

In addition, outside-in is inherently pessimistic, thus human interaction--to resolve exceptions and apply business context--is expected and must be accommodated. The platform must also support versioning and the persistence of services, as well as policies to maintain whatever business rules or policies were in place at the inception for the life of each long-running transaction.

Policy-driven interoperability is at the heart of an outside-in architecture. The policy layer may be a combination of human input and ongoing extraction from a variety of legacy systems or other data sources. In addition, because there are so many participants, a centralized policy must govern authentication, access, and entitlement of participants to underlying workloads. Interoperability applies not just at a systems level, but for varying levels of technology and sophistication; the architecture must accommodate a range of technologies, including offline modes such as voice and hardcopy.

What To Do

Adopting an outside-in architecture can involve a fundamental shift in thinking and execution. For the CIO and IT team, it requires skills in managing and orchestrating many moving parts, across organizations and geographies.

About the Author(s)

Never Miss a Beat: Get a snapshot of the issues affecting the IT industry straight to your inbox.

You May Also Like

More Insights