Re-invent Software Delivery and Offer Your Business as a Service

As business leaders focus on growth during 2012, they are identifying business expansion and transformation opportunities.  The resulting IT mandate to rapidly evolve mobile and social interactions is forcing CIOs to re-invent their software delivery.  By following a straightforward four-step plan, CIOs can improve productivity, enhance agility, deliver timely solutions, and help fulfill strategic business growth goals.

Strategic business growth goals often include delivering new lines of business, selling through new distribution channels, expanding into new geographical markets, simplifying business workflow, delivering services directly to customers, and interacting through mobile channels.  A limited capital environment and short investment timeframe requires building a flexible business service model, which relies on customizing existing products and operational models.

The execution plan should highlight capability configuration and rapid, efficient business service delivery.  Business leaders often specify branch in a box,  localization and centralization, and on-demand self-service terms to indicate doing more with less, fulfilling local compliance regulations while preserving core business processes, and quickly delivering a comprehensive solution into remote areas.

Today’s business evolution pace reduces the optimal time to market and decreases the available IT execution window.  In many organizations, re-inventing software delivery is a pre-requisite before effectively executing business strategies.  CIOs are tasked with determining how IT technology, processes, and organizational models must change. When determining whether your IT organization should re-invent software delivery to enhance execution, consider your existing architecture flexibility, team productivity, and historical time to market.

For example, a well-known business supply company asked the IT team to deliver a mobile application within 90 days.  The business required a complete, mobile shopping and checkout experience mirroring the company’s online ecommerce website.  Unfortunately, the existing application architecture lacked critical, required functionality inside the website.  The code base exposed only 50 percent of the required ecommerce business processes.  One year later, the company finally released the mobile application, and the business viewed the CIO’s team as a market growth inhibitor.

A CIO for a property and casualty insurance company authorized a service-oriented architecture (SOA) initiative in September 2003.  Seven years later, the CIO was being questioned about a $3 million yearly budget line item.  The line item funded the IT-led SOA initiative.  The CIO’s directors could not quantify the business value derived from the SOA initiative and stated that the initiative would take three more years (and an additional $9 million) to complete.  The business continually questioned the IT team’s service development productivity and fiscal responsibility.

A third CIO leading a financial services company owned a monolithic, legacy Web application architecture.  Although the architecture was only four years old, the architecture impeded the organization’s ability to deliver new lines of business and match the expected business volume.  Executive management was hesitant to migrate the application to another platform due to the business disruption encountered during the last platform rollout.  The IT team was unable to quantify the risk and value expected by a new platform initiative, and executive management perceived the CIO as pursuing new technology for technology sake.

Re-invent software delivery

All CIOs must continually lead their teams to improve how projects are designed, developed, deployed and measured.  Transformation charters commonly specify improvement through agile development methodologies, outsourcing, deploying pre-packaged applications, implementing SOA, or adopting platform-as-a-service (PaaS).  When scaling IT initiatives to meet business goals, a strategic, CIO-led technology plan is often required to overcome organizational inertia and re-invent software delivery.

Consider the following four-step strategic technology plan to re-invent the software delivery process:

  1. Identify core business capabilities and outsource commodity.
  2. Iteratively build extensible, configurable business services, APIs, and applications.
  3. Increase business partnerships with API management that provides on-demand, self-service and analytics.
  4. Host services, APIs and applications on a multi-tenant platform and facilitate per-tenant configuration

Step 1. Identify core business capabilities and outsource commodity

When teams gain consensus on their core business capabilities and define non-core, commodity processes, they have established a foundation to focus development effort and increase IT impact.  Non-core, commodity processes should be outsourced and supported by packaged applications.  Reducing bespoke, custom development frees resources and directs the team towards generating meaningful competitive advantage.  Business capability modeling is a technical discipline closely aligned with business process improvement.  CIOs should allocate a few smart architects to work with existing business process improvement experts (e.g. Six Sigma Black Belts, Kanban experts) and track core business capabilities.

A registry can be used to track the intersection between business capabilities and application assets.  Ideally, the registry would be linked with the operational configuration management database (CMDB) to provide a complete view of how business capabilities are instantiated across the IT environment.

Step 2. Iteratively build extensible, configurable business services, APIs, and applications

Pre-built functionality reduces time, effort and resources required to field new solutions.  When building services and applications, the architectural principles of extensibility and configurability will create opportunities to adapt solutions for new geographies, product lines, and markets.  Architects must be adept at identifying the commonality from the variability, and teams must iteratively build solutions to evolve and endure, rather than build for single use or to throw away.  Effective CIOs establish architecture review and governance boards to consistently evaluate development, align extension points with the business strategy, and iteratively enhance the portfolio.

When the organization identifies strategic growth opportunities in developing economies and new markets, application architecture must shift from silos and toward services.  Silos decrease business efficiency by fragmenting the user experience, increasing data management challenges, and fostering process isolation. Agile methodologies highlight inclusive engagement and user feedback.  With the correct focus, development initiatives can unify workflow, foster collaboration, facilitate consistency, and promote solution cohesion.  A complete, composable, cohesive, and interoperable middleware platform will encourage holistic service development.

Step 3. Increase business partnerships with API management’s on-demand self-service and analytics

Many CIOs experience rapid portfolio proliferation and sprawl, but not enhanced portfolio efficiency or business agility.  Achieving business agility requires the growth of development partnerships and interactions, which should span both internal and external teams.

Traditional SOA and integration platforms enable rapid development, but they provide little business partnership support.  Teams commonly operate independently and autonomously.  Hundreds of people write new APIs and services; few people know:

  • who is consuming APIs and services,
  • who is writing re-usable APIs and services, or
  • how APIs and services are being used.

Teams must improve cross-team (or cross-partner) communication, coordination and collaboration.  CIOs should encourage their teams to extend the governance registry and offer managed APIs through an API Store.  A managed API is:

  • Actively advertised and subscribe-able
  • Available with an associated, published service-level agreement (SLA)
  • Secured, authenticated, authorized and protected
  • Monitored and monetized with analytics

An API Store is a venue to find, explore, subscribe and evaluate available resources.  The API Store enables partners to quickly find relevant APIs.  Once a candidate list is identified, the API Store provides a structured environment for exploring the APIs and understanding solution fit.  During the exploration phase, collaboration between the potential API consumer and provider is essential.  After finding and exploring an API, a project may stall when the team attempts to gain access.  An API store provides on-demand self-service subscription and collaboration channels, rapidly reducing the time and effort required to integrate and evaluate available API resources. Figure 1 illustrates API consumer lifecycle activities.

API Consumer Lifecycle Activities

Figure 1: API Consumer Lifecycle Activities

When selecting APIs, trust is an important consideration.  Without trust, potential business partners will choose other alternatives or build their own solution.  CIOs must establish an environment where their team is the trusted provider of choice.  When teams follow best practices, partners recognize competency and reduce their adoption trepidation.

Teams increase competency when they establish a separation between API provider and API manager responsibilities.  An API provider is responsible for building, publishing, scaling and versioning the API.  The API manager is focused on promoting and encouraging potential consumers to adopt the API.  The manager analyzes usage patterns and determines how to best monetize the asset.  A monetization strategy solve a perennial IT questions:

  • Once I offer an API, what should be the show-back, charge-back mechanism?
  • How do I actually perform investment re-capture activities?

Step 4. Host services, APIs and applications on a multi-tenant platform and facilitate per-tenant configuration

Offering a business capability as a one-size-fits-one API is a typical IT solution trap.  One-size-fits-one solutions do not exhibit the adaptability or agility required to fulfill new business opportunities. CIOs are intrigued by the cloud’s promise to create a one-size-fits-ALL solution.  Cloud characteristics and vertical PaaS accelerate the IT team’s ability to deliver solutions that support business growth objectives.

Cloud characteristics advance a company’s ability to offer business capabilities as on-demand services.  Cloud characteristics describe IT’s ability to deliver on-demand self-service, rapid elasticity, resource pooling, and measured service.  Figure 2 associates cloud characteristics with architectural goals.

Cloud Characteristics

Figure 2: NIST Cloud Characteristics and associated architectural goals

On-demand self-service and resource pooling will flexibly assign workloads and decrease provisioning periods.  If teams excessively customize an environment, they can increase time to market, lower resource pooling, and create a complex, one-size-fits-one environment, which is difficult to manage and maintain.  A CIO should encourage a governance process that minimizes exceptions.  Consumers in a one-size-fits-all environment will predominantly subscribe to standard service offerings.

Business users don’t really care how many server instances are running in the cloud.  Business users care about business entities, business activity performance, and associated cost.  A CIO who decouples metering and billing from IT assets and shifts the reporting model to focus on business activity cost will positively transform investment conversations.

When you pre-build vertical industry APIs and vertical industry components, you can decrease time to market, bring new partners online, and create new revenue sharing opportunities.  With a vertical PaaS, your organization offers vertical business capabilities using a multi-tenant, extensible cloud environment.  The environment decreases time to market for partners, creates new ecosystem scenarios, and enables revenue sharing opportunities.

The vertical PaaS environment also provides an opportunity for your partners to deeply embed your business capabilities within their applications (similar to, eBay sellers, or Amazon Store environments).  By hosting all business partners (e.g. suppliers, customers and employees) within a multi-tenant environment, the environment can easily aggregate and share business information. Figure 3 illustrates how a complete middleware platform, API management, and vertical PaaS deliver an ecosystem platform.

Vertical PaaS Figure 3: Vertical Platform as a Service Environment


Today’s business evolution pace reduces the optimal time to market and decreases the available IT execution window.  The resulting IT mandate to rapidly offer core business capabilities as configurable services is forcing CIOs to re-invent their software delivery.  A strategic plan can keep your team on track.  Guide your team towards identifying core business capabilities, building extensible and configurable business services, increasing business partnerships, and building a business ecosystem.  As your business ecosystem emerges, your organization will encounter new revenue sharing opportunities, and an opportunity for your partners to leverage your core capabilities in ways that you haven’t yet envisioned.

 Related Resources

What is PaaS?

WSO2 API Manager



Leave a Reply