What is wrong with application rationalization?

Lots of organizations I speak with are undertaking rationalization and simplification of application portfolios - some successfully, some less so.  I think that the key difference between successful and less successful rationalization is the order in which organizations go about it.  Organizations that rationalize their applications successfully start with (1) business drivers that define the need for change, then (2) they define the characteristics of the application portfolio that will enable those business changes. They then (3) outline a program of phased activities that will deliver the portfolio changes and finally (4) undertake a series of projects that make the functional, technical or process changes.  Less successful programs take a different sequence - it typically goes in a 4-2-1-3 sequence, starting with projects, then portfolio changes, which deliver some business change that are wrapped up in a program.  

 
Read more

What makes a great application owner?

Application owner or application product manager roles are increasingly common in many organizations and these roles play a critical part in application rationalization efforts. Organizations fill these roles with staff from a diverse range of backgrounds including enterprise architecture, business analysis, application development and business operations.  In some cases, it is not a discrete role, rather an additional responsibility for an individual staff member or group of staff members.  However the role is organized and structured, it is important both in terms of accountability for the application as well as defining and delivering the application's direction and value add.  So what are the key skills or characteristics that makes this role successful? What are the knowledge domains, behavioral characteristics and aptitudes that differentiate high performers in this role?

 
There are four primary areas of domain knowledge (with knowledge defined as familiarity, awareness and understanding gained through experience or study) that can inform the profile of domain skills your organization may require:
- Technical knowledge —how does this application work and what are its effects?
- Business-specific knowledge —what makes our organization work operationally and culturally?
- Process knowledge — which processes fuel our organization and its competitive edge?
- Industry sector knowledge — which forces, markets and models characterize our industry sector.
 
Read more

Responding to the EA skills quest

EA organizations are under increasing pressure to contribute tangibly to business results and to differentiate in greater terms than architectural domain skills alone.  At the same time, compressed business cycles compel organizations to respond to events or opportunities at a more rapid pace.  This often means resourcing and organizing into effective teams and projects quickly.  EAs are often involved in multiple projects and teams and expected to have sufficiently broad experience, combined with multiple competencies to contribute to organizations’ responses.  Many EA organizations see this skills tension increasing and often struggle to sufficiently develop or resource teams for the ever growing number and diversity of issues they are involved in.  Increasingly, the contextual application of EA to real organizational issues and new opportunities is overtaking the traditional role of EAs in many businesses.  For many EA teams and their stakeholders, the way in which value is derived from investments in EA is through increased contextualization and enhanced adaptability.

 
Read more

The architectural implications of shared services

 

Shared services is widely employed in many industry sectors and is gaining increasing traction as organizations, particularly those subject to continuing cost pressures look for ways to control costs.  For example, in December 2012 the UK government set out its next generation shared services strategy to enable savings of £400-600m per year.  Shared services take many forms, but regardless of the type of shared service, when properly executed it can deliver a range of benefits.  Benefits can result from economies of scale or scope, the ability to negotiate from a stronger consolidated base and through adoption of streamlined, common business processes.  A shared services model can also enable groups to share knowledge and best practice as well as the services themselves.   However, these benefits must be balanced with the flexibility clients (internal or external) require. 

Shareable services typically include corporate service processes such as HR, procurement and finance and accounting. Sharing of enabling capabilities typically include IT infrastructure, workflow, data repositories as well as domain-specific expertise and resources.  Viewed as business services, they can be defined in terms of outcomes and external dependencies using a combination of deliverables, processes, roles, and skills.  This way EAs can help position the shared services within the organization’s architectural construct in terms of service provision to other functions within the business or to external partners or customers.

Read more

Does BYOD mean BYO architecture?

The rise of bring-your-own-device (BYOD) programs in organizations is well documented and it is a growing trend that shows few signs of slowing down.  The benefits in increased worker flexibility and improved modernity of the working environment can often outweigh the various and well documented technical, legal and operational concerns.  The architectural implications are equally important and often less well understood.  The architectural view on BYOD can take multiple perspectives, for example: a device view, a centralized infrastructure view or a usage focused view.  Common components such as support, management and security apply all of these architectural views.  Each view provides a discrete perspective of the architectural patterns required to successfully architect for BYOD. The selection of the right view for your organization depends largely on the organizational environment in which it will be employed. Irrespective of the view employed, key to architectural success with BYOD programs is to identify and plan for critical aspects of a BYOD scenario based on the different architectural views.

Read more

When Does Standardization Make Sense?

Standardized IT systems can appear to make a lot of sense – standardization can be cost efficient, aligned with industry approaches and can help promote re-use.  However, the business advantages standardization yields can be easily replicated by competitors.  So what are the trade-offs and when does it make sense to choose standardization?

Standardization is typically preferred when cost efficiency is the motivation and/or when there is a requirement for interoperable IT components and process interfaces.   The cost motivation is straightforward and is particularly appealing to organizations that are subject to cost pressures in their own market. Selecting standardized technology can yield immediate savings. The combination of multiple suppliers and ease of interchangeability creates a buyer's market. This can stimulate ongoing price reductions.  The drive to achieve cost efficiency through standardization can be seen in all stages of technology deployments.  In the design stage, selecting standardized technologies can increase interoperability and reduce complexity in system design. In the deployment stage, standardized products can enable a more predictable operating environment that is typically less costly to manage. In the operational stage, use of more standardized technologies may increase access to skilled personnel.  Interoperability is an increasing concern for many organizations, especially those that operate in markets where eco-systems and partnerships are critical factors or those markets in which merger and acquisition activity is common. The process of linking or bringing together multiple heterogeneous IT systems can be greatly simplified when IT environments are built from highly standardized systems.  

Read more

Solving the Complexity Conundrum

'Reducing complexity' is a reason frequently given by organizations when instigating an application rationalization initiative.  However, complexity can be challenging to define and measure in all but subjective terms.  For many organizations embarking on rationalization, the primary focus is the reduction or elimination of complexity.  Complexity is often associated with higher costs and reduced adaptability or agility.  However, where the value of complexity to the organization is high (due to the competitive advantage or ability to maintain/defend a market position and brand equity), these may be prices worth paying.  EAs play a critical role in defining those areas where complexity can add value and what the trade-offs are.  This enables organizations to take a more rounded view of complexity in the context of application rationalization.  

Complexity to Achieve Market Differentiation
When competitors use similar IT systems, their capabilities and efficiencies in serving customers probably will be similar to yours. In effect, this makes organizations more interchangeable. To mitigate this, organizations seek an edge in terms of service differentiation, capability or cost. This consideration is particularly important in highly populated marketplaces. For example, many services organizations use quality of service or customer reputation as key tools for online sales. This means that IT capabilities and efficiencies play a major part in defining these organizations' relative market positioning.  
Read more

What is the right number of applications?

A common question Forrester gets from organizations planning an application rationalization strategy is “How many applications should I aim for?”  It is a good question, but can be symptomatic of an approach where less equals success.  This is very common with executives and senior stakeholders, who often can take this type of singular view of application portfolios.  While it is a straightforward way of examining your application portfolio, inherently it is a binary dimension.  It does not account for the multiple prisms through which organizations should view and make decisions about their application portfolios.

 

Enterprise architects can help organizations determine where their objectives are placed on a wider range of applications continuums than just the number of applications, for example:

§  Customized Vs Standardized– What degree of customization do my organization's applications require?  What differentiation does standardization provide?  What is the opportunity cost of customization?  What is the right balance for my industry sector ? 

§  Control Vs Freedom – What level of freedom on application choice best serves my organization?  How much control of the application portfolio is appropriate or mandated for my market and what is the cost of this?  What is the cost/benefit of decentralization of choice compared with control of choice? 

§  Centralized Vs Localized – What differentiation is provided by localized applications?  What is the opportunity cost of centralized applications?  What is the right balance of localized differentiation and centralized standardization for my organization?

Read more

What is on your EA To-Do list for 2013?

One of the great things about working in enterprise architecture is the opportunity to work on a diverse range of initiatives.  Findings from our Global EA Maturity Survey in Q2 2012 show it is going to be a busy 2013 for enterprise architects:

Top Priorities for 2013

While variety is to be expected in the enterprise architecture role, EAs will be multi-tasking more than ever.  As businesses increasingly experience the value of enterprise architecture, the demands on the EA function increases also.  It is a good problem to have - but it is a problem nonetheless.  Equally, many of the priorities are linked and progress (or lack of) in one area informs another. For example, strengthening emerging technology processes and simplification of the application and technology portfolio are interlinked.  At the same time, many businesses expect results in shorter timeframes and some of the priorities are inherently longer-term and deliver over an extended period of time - which is not always fully appreciated by stakeholders.  These are clearly challenges and although it will be a busy year, EAs can look ahead with confidence.  Demand for EA services are growing.  Businesses are looking for more from their EA functions, in more parts of the business - and the opportunity for developing the scope, importance and relevancy of EA is ever growing.