Finding the sweet spot between ‘need to share’ and ‘need to own’
For decades, businesses typically have been rewarded for consolidation around standard processes and stockpiling assets through people, technology and goods. Companies are discovering they need a new kind of leverage – capability leverage – to mobilize third parties that can add value. Outside-in architecture requires an organization to think about its operations and processes as a collection of business capabilities or services. Each individual service can then be examined to determine how it can be most effectively fulfilled – either by strategically standardizing on existing package solutions or custom technology investments; or by sourcing through platform, software or business services available through the cloud. This architectural transition requires new skills from the CIO and the IT organization. CIOs who anticipate and understand the opportunity are likely to become much more effective business partners with other executive leaders.
Read more about Outside-in Architecture
Chief Technology Officer
Rearden Commerce’s business is largely focused on the travel industry. Our job is to help connect travelers to the services they need – housing, airfare, ground transportation and special services. By definition, we’re dealing with a fragmented industry, with a multitude of “outside” constituents and resources, from the biggest airlines to mom and pop travel shops. Outside-in architecture is the air we breathe.
Our technology platform needs to act like a global distribution system – one that can integrate with cutting-edge technologies one minute or mimic the cryptic 3270 terminal commands to a legacy booking system the next. And one that can route requests based on the ever-changing needs of the traveler across a fluid collection of service providers.
From the start, we faced a number of outside-in challenges, starting with policies. In business travel, policy is a big deal. For example, consider issues of determining which employees are allowed to fly first class, or the need to stay within preset budget limits, or the challenge of keeping track of individual travel preferences. Our approach evolved to externalize policy from the code itself, allowing policies to be expressed based on individual customer needs and preferences. As you can imagine, this wasn’t something we were able to accomplish overnight. We had to rewrite virtually all our code to make our policy external. And, as you add partners to the platform, there’s a greater demand for policies to be both transparent and external, rather than inherent to the platform.
While this has been an enormous amount of work, it’s well worth the effort. Travel buyers appreciate the fact that these systems understand their individual preferences and requirements – the context is automatically defined. For travel providers, having direct, transparent access to policies helps them to operate more efficiently and deliver the tailored services that keep customers happy. Sharing more information, more intelligently, is a good thing.
An outside-in approach has also made it easier to dive into new technologies such as cloud and mobile, because we start with a services mentality. Mobile, for instance, is a logical extension of what we do, and our technology platform has shown to be an excellent foundation as we introduce mobile offerings. As we move deeper into the cloud, we expect to find the same to be true. These capabilities can also allow us to expand the reach of our transparent, outside-in approach among travel consumers and service providers alike.
Where do you start?
Outside-in architecture should not be relegated to the role of an academic exercise or thought experiment. The concepts are real and tangible. However, they do represent a series of significant shifts for the enterprise, which should reconsider everything from how business processes are envisioned to the lowest level of the technical operating environment.
The good news is that companies can make the migration to outside-in architectures pragmatically, starting with efforts to access and mobilize third-party resources. These initiatives can often be launched with modest, short-term efforts. Begin by exposing the necessary internal resources through wrappers – and by making them available to specialized policy and interaction servers – rather than trying to re-architect everything inside the enterprise. For example, Rearden Commerce has been migrating to an outside-in architecture for several years through a staged effort, while continuing to run its core business and support growth rates.
Before the technical architecture and the migration path get locked down, though, the following issues should be considered from a business and technical perspective:
- Business service decomposition. Don’t make any moves around orchestration and policy layers until you take a step back and deconstruct your business into coarse capabilities. These should then be decomposed into business services. Avoid process definition traps, since the order of sequential steps is less important at this point than articulating the steps themselves. Make sure the semantics and context used to describe services are business-based. The point is to loosely couple the architecture, separating business architecture from the applications, data and infrastructure.
- Look for diversity. Focus early on business areas with a large number of existing or potential service providers, or areas with high volatility in business rules or policies. The real potential of outside-in is to create value by orchestrating demand with the most effective supply in dynamic markets.
- Long-running interactions. Another source of opportunity is any business service with extended time between start and finish. The pessimistic architecture of outside-in can allow for exceptions to be properly handled and any manual workloads to be effectively handled.
- Look at the edges. Early and effective outside-in migrations take place at the edge of an organization’s core platforms. Ancillary value creation opportunities involve more active collaboration with third parties, and allow both the business and the technology organizations to introduce outside-in concepts and gain real world functional and technical design experience. That learning can then be applied to the broader organization.
- Innovation revolution. A disciplined approach to innovation, whether internal or external, can identify candidates to anchor an outside-in architecture transformation. Does a peer business unit have a better dynamic pricing engine? Outside-in architecture can take localized innovations and help drive them to enterprise assets. Does an external rating service provide real-time information that makes your product’s value proposition clearer to customers? Incremental additions from external sources can help illustrate the value of outside-in and provide the catalyst to get business and technology providers on board.
Outside-in architecture institutionalizes the ‘need to share’ philosophy that is required as ecosystems get more complex, constituents get more social and business factors change at Internet speed. There are some nuances and technical implementation details, but the most critical step is to identify specific opportunities to connect with a large number of other businesses in arenas where performance is under growing pressure. Consider starting by exposing IT resources, applications and data using wrappers with the specific goal of accessing complementary resources that can help drive performance improvements. The good news is that there are pragmatic pathways for enterprises to potentially reap early benefits of outside-in architectures, without requiring a massive re-architecture at the outset.
As used in this document, “Deloitte” means Deloitte LLP and its subsidiaries. Please see www.deloitte.com/us/about for a detailed description of the legal structure of Deloitte LLP and its subsidiaries. Certain services may not be available to attest clients under the rules and regulations of public accounting.