White paper written when Architecture Function was in its infancy. The focus of the white paper is on Business -IT Alignment of Enterprise Architecture

1. Author:
Sudhir Nilekar
© 2008, All rights reserved.
CRYSTALLISING THE ENTERPRISE CUBE
For Industry Executives

2. 2
Table of Contents
Executive Summary.................................................................................. 3
1 Introduction ..................................................................................... 5
1.1 Stakeholders ............................................................................... 5
1.2 Crystallising the Enterprise Architecture Cube...................................... 5
1.2.1 Business Drivers- Value Proposition................................................. 6
1.2.2 Enablers – Business Processes ........................................................ 6
1.2.3 Facilitators – Business Support....................................................... 8
2 Enterprise Cube for Stakeholders............................................................ 9
2.1 Business Drivers – Value Proposition................................................... 9
2.1.1 Growth, Sustainability & Return on Investment (ROI)........................... 9
2.1.2 Differentiation.......................................................................... 9
2.1.3 Term Planning .........................................................................10
2.2 Enablers – Business Processes..........................................................10
2.2.1 End-to-End Lifecycle .................................................................10
2.2.2 Business Functions ....................................................................11
2.2.3 Business Metrics .......................................................................12
2.2.4 Growth Orientation ...................................................................13
2.3 Facilitators ................................................................................14
2.3.1 Facilitator Model ......................................................................14
2.3.2 Application Model .....................................................................15
2.3.3 Data Model .............................................................................18
2.3.4 Integration Model .....................................................................20
2.3.5 Infrastructure Model..................................................................22
3 Conclusion ......................................................................................25
Acronym Key .........................................................................................26
References ...........................................................................................27
Figure 1- Enterprise Cube.................................................................................................................................................5
Figure 2 - Industry Specific Value Propositions...........................................................................................................6
Figure 3 - Industry Specific ‘Enablers’.........................................................................................................................7
Figure 4 - Business Process Functions View............................................................................................................... 11
Figure 5 - Business Metrics............................................................................................................................................ 12
Figure 6 – ‘Expected’ Application Model TCO .......................................................................................................... 17
Figure 7 – ‘Misfit’ Package Application TCO............................................................................................................ 17
Figure 8 - Data Model Framework ............................................................................................................................... 19
Figure 9 - Integration Model......................................................................................................................................... 20
Figure 10 - Infrastructure Model.................................................................................................................................. 22
Figure 11 - Enterprise Cube Evolution ....................................................................................................................... 25

3. 3
Executive Summary
‘Enterprise Architecture’ has been in focus in the recent past, for organizations to leverage existing
assets and build a ‘Services Oriented Architecture’ (SOA) platform. The pursuit to build a SOA
platform, often driven by Information Technology stakeholders, tends to start and stop at the first
step. The first step being a comprehensive and systematic ‘inventory list’ - with architectural
principles and guidelines - of the existing Information Technology (IT) landscape. However, this
pursuit relegates the Business factors that architect the IT landscape to the background. The reason
for this is it is takes clinical diligence and discipline on the part of stakeholders to connect the
architectural principles and guidelines between the Business and IT. To establish the ‘Business – IT’
connection, stakeholders from Business domains need to proactively contribute for building the SOA
platform from an overall enterprise perspective. The ‘Business – IT’ connection is based on three
foundation pillars, which are:
• Business Drivers – Value Proposition for customers
• Business Process – Enablers for the value proposition
• Business Support (Operations & Information Technology – OPIT) – Facilitators for the
business drivers and business processes
This papers aims to bring out the cause-effect relationship for a ‘Business-IT’ connection by
mapping the three pillars along the axes of a 3 dimensional cube called the ‘Enterprise Cube’ (EC).
Each axis of the EC is evaluated using business principles (adopted by Lord Simon Marks1
and Taiichi
Ohno2
) of:
• Product/ Philosophy: Value Proposition for customers
• People: Stakeholders who deliver the value proposition
• Process: To define efficient and effective means to deliver the value proposition
• Place: Being globally ‘local’ to deliver the value proposition
Business Drivers, Business Enablers and Business Support form the three axes on the Enterprise
Cube. Business Drivers axis always leads the other two axes. Importantly, the closed loop from
Business Enablers & Business Support provides the necessary feedback to Business Drivers to drive in
the direction of maximizing the Return on Investment (ROI). Also, the closed loop feedback helps
maintain a common end goal for all stakeholders.
The complex inter-dependence of Business Drivers, Business Enablers and Business Support on the
Enterprise Cube axes has to be understood by stakeholders to establish the ‘Business – IT’
connection. It lays the foundation for a Services Oriented Business Architecture that leads the
way to a genuine Services Orientated IT Architecture. Unless the Business Architecture is worked
out efficiently, it will be unclear where Information Technology will facilitate to support it.
Information Technology without efficient business architecture is analogous to being afloat by a
powerful buoy with 1000 kilo load tied to the feet.
Thus, the fact is - for an Enterprise to move ahead in today’s constantly evolving world, there are
different forces to control and throttle – as against the common perception of IT as a panacea for
all ills
1
Chairman of Marks & Spencer from 1916 – 1964 and who was responsible making M&S as one the worlds leading retailer till mid-
1990s
2
Founder of the Toyota Product System (TPS) which led to Toyota’s unparalleled success in market share, profitability, quality &
market capitalization

4. 4

5. 5
1 Introduction
1.1 Stakeholders
The business model for every enterprise operates from three main perspectives: Business Drivers,
Business Process and Business Support (Operations & Information Technology – OPIT).
Each perspective is relevant to different set of enterprise stakeholders as given below:
Business Drivers: CEO, VP, Directors, Business Unit/ Division heads, C-Level Executives
(responsible for the P&L statements), CIO, Enterprise Architects
Business Processes: Process Owners, General Managers, Operations Managers, Business
Analysts, Solutions Architects; individuals who define business process specifications to align
the same with the business objectives. Typically, multiple processes are required for Business
Drivers
Business Support (OPIT): Enterprise/ Solution Architects, Operations Managers, Business
Analysts, Business/Systems Analysts, Programmers; individuals responsible for transforming and
supporting business processes into operational procedures – using Information Technology or
otherwise – to provide the most efficient and effective way of achieving the ultimate business
objectives
1.2 Crystallising the Enterprise Architecture Cube
Figure 1 depicts a generic ‘Enterprise Cube’ (EC). It provides strategic, tactical and operational
perspectives to enterprise stakeholders along each axis.
Figure 1- Enterprise Cube
An ‘Enterprise Cube’ (EC) defines the space within which the enterprise lives and grows. The EC,
for any organization, defines boundaries within which all growth/development should take place.

6. 6
1.2.1 Business Drivers- Value Proposition
I. Overview
This dimension maps the ‘Value Proposition(s)’ an enterprise offers to its customers – external or
internal. Customers can be individual consumers, corporate consumers, society in general,
environment etc. It defines the breadth of offers to customers in terms of products / services and
acts as a Driver to take the organisation on the growth path
Every new business initiative – which is a value proposition for customers - is a new calibration on
the ‘Drivers’ axis of the EC. This axis holds a strategic perspective for the enterprise stakeholders.
Figure 2 illustrate Value Propositions (Business Drivers) offered to customers in different industries.
Figure 2 - Industry Specific Value Propositions
II. Significance
It is important to note that ‘value proposition’ is purely from an end customer perspective; but
internally for the enterprise, it can be separate business division or can be an updated scope for an
existing business division.
For example, a food retailer may decide to offer home-delivery of white goods to customers. From
a customer perspective, it is a new value proposition but internally, in all probability, it is a new
business division with its own P& L account.
On the other hand, a retailer that already offers ‘Home Delivery’ of white goods may decide to
offer complementary services like ‘installation & removal’, ‘ time-slot based deliveries’ (to reduce
customer wait time) etc. From a customer perspective, the complementary services are a new
value proposition, but internally within the enterprise, in all probability, it is the same business
division with new processes defined.
1.2.2 Enablers – Business Processes
I. Overview
For every ‘value proposition’, there is a set of business processes that enable an enterprise deliver
it. Each business process consists of one or more business functions that define operational details

7. 7
for end-users at all levels. In effect, business processes (along with operational details) define the
‘Fulfillment Chain’ for a value proposition. ‘Fulfillment Chain’ is the upstream supply chain and
the downstream demand chain processes. It
defines functional capability of the enterprise
to deliver what it promises in the value
proposition.
Figure 3 illustrates how business processes (Enablers) can be defined across different industries
Figure 3 - Industry Specific ‘Enablers’
II. Significance
A new ‘value proposition’ or a change to an existing one along the ‘Business Driver’ axis impacts
business process(s) along the ‘Enabler’ axis. The impact depends directly on how different is the
fulfillment chain of the new/modified value proposition from the existing one(s).
Continuing with the previous example, the food retailer who decides to offer home-delivery of
white goods to customers will have to define a completely new fulfillment chain. The primary
reason for this is supply chain processes like procurement/purchasing, supplier management, stock
management, replenishment planning, delivery management, returns handling etc for food products
are significantly different from those for white goods.
On the other hand, the retailer – already offering home-delivery of white goods – and who decides
to offer complementary services like ‘Installation & Removal’, ‘Time-Slot based Deliveries’ etc - has
an existing and working the fulfillment chain in place. To enable the new offerings, existing
processes in the fulfillment chain have to be modified instead of starting afresh. For example, the
existing Delivery Management process can be upgraded to handle ‘Time Slot Based deliveries’ and
existing Supplier Management process can be upgraded to handle ‘Installation & Removal’
‘Enablers’ (business processes) define business
metrics (KPIs) – to measure the efficiency and
effectiveness of the fulfillment chain. The
focus along this axis is predominantly strategic
& tactical.

8. 8
1.2.3 Facilitators – Business Support
I. Overview
To operationalise business processes, an enterprise defines the support framework within which it
operates. The support framework comprises Operational & Information Technology (OPIT) elements
that control:
Information (data) Flow: To provide the operational controls & decision making abilities
Applications Behaviour: To provide functionality to business processes
Collaborative Capabilities: To provide seamless interactions within the enterprise and with the
external world
Infrastructure: To power business operations using physical entities such as office locations,
warehouses, transportation fleet, IT hardware etc
The OPIT elements facilitate (and also limit) the capability of business processes defined on the
‘Enabler’ axis. To optimize costs, the support framework has to be flexible, configurable and
adaptable. ‘Facilitator’ OPIT elements should be a
repository of common enterprise services available
to all value propositions and/or business processes.
This forms the bedrock of a ‘Services Oriented
Architecture’ (SOA) platform for the enterprise architecture.
II. Significance
From an EC stakeholder perspective, changes on the ‘Business Drivers’ axis and/or on the ‘Enabler
axis’ can have a significant impact on the OPIT elements of the ‘Facilitator axis’.
As seen in the previous example, the food retailer offering home-delivery of white goods will have
to define a completely new fulfillment chain. The new business processes necessitate defining
completely new OPIT elements in terms of operational procedures, applications/ systems, data
model, integration requirements & infrastructural support.
On the other hand, the retailer – already offering home-delivery of white goods has existing OPIT
elements (operations, applications, data etc) in place. Hence, the existing OPIT elements may need
some modification instead a setting it up again. For example, the existing Delivery Management
applications can be modified to handle ‘Time Slot Based deliveries’ and existing Supplier
Management applications can be modified to handle ‘Installation & Removal’. The ‘modifications’
of the OPIT elements should ideally be minor updates relative to a completely new set up.
‘Facilitators’ (Business Support) should
be driven by the Services Oriented
Architecture (SOA) philosophy.

9. 9
2 Enterprise Cube for Stakeholders
2.1 Business Drivers – Value Proposition
A new value proposition on the ‘driver’ axis is created due to multiple reasons - internal innovation,
first mover strategy, competitor activity, government regulation(s) etc. Calibrating a new ‘Value
Proposition’ should always be a justified by an objective business case.
Key Stakeholders: CEO, VP, Directors,
Business Unit/ Division heads, C-Level
Executives (responsible for the P&L),
CIO, Enterprise Architects
For stakeholders the parameters to evaluate the feasibility and practicality of a Value Proposition is
detailed in the following sub-sections
2.1.1 Growth, Sustainability & Return on Investment (ROI)
Customer segment: The customer segment can be individual consumers, corporate customers,
governments, etc. It significantly affects the ‘Go – No Go’ decision for a new value proposition
as it directly relates to revenue generation.
Capital Investment: The ‘sunk’ costs of the introducing and maintaining a new Value
Proposition directly impact the ‘Net Present Value (NPV)’ of the company from a shareholders
perspective and the working capital requirements from an internal P&L perspective.
‘Opportunity Cost’ analysis of this investment can a crucial component of the feasibility study.
Industry Specifics: The expertise required to operate or enhance a value proposition can range
from technical expertise as required in the Telco industry to operational expertise in the
logistics/ distribution industry to financial expertise in banking/investment markets. It defines
the people aspect of the value proposition
Industry Maturity: The main objective of a value proposition is either revenue or profit growth.
A mature industry will necessitate the enterprise to focus more on cost reduction and increased
efficiency rather than on market expansion and revenue growth as is the case in the Newspaper
& Magazine industry
Regulations: External factors such as Environmental Impact3
, Corporate Citizenship,
Government policies should be evaluated to ensure that these do not become show-stoppers for
the value proposition in the planned future
2.1.2 Differentiation
The value proposition for an enterprise can be differentiated from competition in two ways –
Product Exclusivity and Customer Service. These create entry barriers for competitors to offer a
similar value proposition. In today’s world, except for specialty products like made-to-order
products such as luxury cars, Customer Service is essentially the main differentiator for every
industry.
The cost of Customer Service is driven by
the Internal Efficiency of enterprises
operations.
Internal efficiency has to be ingrained as a
3
The ‘Carbon Footprint’ of organisations due to activities related to new ‘Value Propositions’ will have to be evaluated
comprehensively - right from the impact of the manufacturing of the product/ service to time its is disposed off by the end
consumer.
‘Customer Service Differentiation’ (Low
Entry Barrier) is driven by ‘Internal
Efficiency Differentiation’ (High Entry
Barrier)
The Business Case should be effective enough to
enable key stakeholders make the ‘‘Go – No Go”
decision for the new value proposition; before the
enterprise embarks on the comprehensive exercise
of defining & crystallising the ‘Enablers’ and
‘Facilitators’

10. 10
philosophy within of the enterprise and cannot be bought in the market.
For example, many global automobile companies have failed miserably to adopt the ‘Lean
Manufacturing’ principles as per the Toyota Production System (TPS). On the other hand, in 2002,
Toyota’s return on assets (ROA) was 8 times higher than the industry average and it made a profit
every year for the last 25 years and had $20 - $ 30 billion cash in bank.4
2.1.3 Term Planning
Term Planning overlays the new value proposition on the backdrop of time horizon i.e. from
inception to operationalisation to ROI. It helps stakeholders identify the magnitude of investment
in that period required for the value proposition. Also, Net Present Value of the enterprise can be
calculated by appropriately discounting future cash flows in that time horizon. This is particularly
true for larger enterprises with diverse value propositions where multiple value propositions need
to be evaluated in parallel.
Term planning helps stakeholders prioritise the effort and investment decisions for parallel value
propositions.
2.2 Enablers – Business Processes
For a value proposition on the Driver axis, the Enabler axis owns the corresponding Business
Processes. Business processes deliver the value proposition promised to customers. This section
details how stakeholders can align business processes with the value proposition objectives.
Key Stakeholders: Process Owners, General Managers,
Operations Managers, Business Analysts,
Solutions Architects
2.2.1 End-to-End Lifecycle
Level 1 business processes are connected together to map the end-to-end lifecycle of products /
services offered by the Value Proposition. End-to-end lifecycle typically can be classified in 3 main
areas as:
Planning Processes: For Example,
o Product Market Planning
o Demand Forecasting
o Replenishment
o Transport Planning
o Supply Planning
Execution Processes: For Example,
o Customer Fulfillment
o Customer Returns/ Maintenance
o Supply Management
Supporting Processes: For Example,
o Master Data Set Up: for supply chain players, products/ services, business rules
o Validation & Authorisation: Payments, Addresses, Products, Fraud
o Inventory Management: Stock control, stock transfers, allocation rules
o Financial Processes: Pricing, Payments, Refunds, Remittances, Chargebacks
o Asset Accounting: Stock valuation, operational costs
Lifecycle Processes can be defined and managed
in a centralized and/or a localised manner. The
decisions depend on a number of factors such as
market demographics, product characteristics,
corporate strategy etc
4
‘The Toyota Way’ – Jeffrey K. Liker
Stakeholders should define Business
Metrics – Key Performance Indicators
(KPIs) and Key Result Areas (KRAs) -
on the Enabler axis
‘Localisation’ may be due to multiple
factors such as geography, demographics,
multi/ cross channel operations,
government regulations, mergers and
acquisitions, industry specific requirements

11. 11
2.2.2 Business Functions
Every process is made up of one or more Business Functions. Business Functions define operational
details of a process from an end user view. Operational details for business functions can be
grouped as per the Business Process Areas:
Planning Process Functions: To provide the business intelligence to the execution and
supporting processes from a ‘future’ perspective
Execution Process Functions: To define the end-user activities in the process execution space
Supporting Process Functions: To define the end user activities for supporting the Planning and
Execution processes. Typically, supporting process functions should provide common services
across value propositions
Business Functions directly impact the operations of internal and external users. The objective of
defining business functions for a value proposition should be to simplify the end user experience by
abstracting details at a user level. Figure 4 illustrates how business functions – across execution,
support and planning processes - are abstracted to keep it simple and easy to understand from a
customer view.
Figure 4 - Business Process Functions View
Operational specifics of business functions for execution, supporting and planning processes are
predominantly defined by industry verticals. For example, business functions in different industry
verticals include:
Telecom
o Ability to provide customers to ‘Configure Value Propositions’ like landline + internet,
payment plans, optional services etc
o Enterprise capabilities to ‘Activate/ Enable services’ as per customer orders and
‘Contractual billing’ as per usage of services and so on.
Retail

12. 12
o Providing ‘stock availability’ to customer at point-of-sale (PoS)
o Enterprise capability to optimize fulfillment costs by ‘rules based of fulfillment centre
selection and allocation’
Logistics & Distribution
o Ability to provide granular ‘Expected Time Delivery’ to customers
o Enterprise capability to minimize ‘cost/ delivery’ by optimized Transportation Planning
Financial
o Ability to have shorter ‘account opening’ for customers across multiple channels
o Ability to create credit provision in declining markets
o Ability to minimize costs by outsourcing
Irrespective of the industry vertical, business functions should be defined to provide granular
visibility and control of transactions across all channels, geographies and related business
processes.
From a stakeholder perspective, every business function helps define investment costs such as:
People/ Personnel
Physical Assets
Business Support (in terms of Operations, Information Technology and collaboration with
external parties)
2.2.3 Business Metrics
Every business process can have one or more metrics to objectively assess its alignment with the
value proposition. Business metrics should be defined from stakeholder perspective to assign
defined ownership to relevant people. This introduces formal and articulate sharing of information
between stakeholders across the Business Drivers and Enabler axes of the EC, as depicted in Figure
5.
Figure 5 - Business Metrics

13. 13
The parameters5
that drive business metrics include:
Direct Costs
o Number of people
o Day-to-day operational costs to deliver the value proposition
o Stock Holding Costs
o Business Support (in terms of operations and IT infrastructure)
o Recruitment and Training Costs
o Cost of adapting processes as per business changes
o Marketing/ Brand building costs
Derived Costs: These costs are often hidden (as these are not explicit ‘Expense Items’ on a P&L
statement) and/or ‘Activity Based’ such as:
o Time to complete an order (in contact centres)
o Lost sales
o Time to get complete visibility of customer orders
o ‘Order – to –Delivery’/ ‘Offer – to – Cash’ cycle time
o Re-processing/ Manual Intervention
o Exception handling
o Returns Processing
The obvious utility of business metrics is to measure the effectiveness and efficiency of business
processes in delivering the value proposition. The not-so-obvious impact of business metrics is its
influence on public perception and how attractive is the enterprise for new talented people -
which are critical in terms of growth for the enterprise
2.2.4 Growth Orientation
Business processes and related functions should be based on the premise of enterprise-wide
commonality and future changes. Supporting business process functions such as ‘Validation &
Authorisation’, ‘Invoicing’, ‘Master Data Set Up’ etc are often common across the different value
propositions, irrespective of the industry. This commonality should drive modularization of
business process functions. Each business function module should be flexible, adaptable and
granularly traceable to requirements.
Business process modules should be evaluated
on short, medium and long term time horizons.
It helps make investment decisions by analyzing
the ‘Opportunity cost6
’ of the process modules.
Consistency and standardisation in capturing critical information for each business function module
delivers objective results and reduces people dependency. Standard methodologies such as Activity
Models, Input-Control-Output Model, Class Models and Use Case Model can be employed to define
process modules. Key elements that define a process module include:
Process functionality
Business rules
Operational details
Roles and responsibilities of the end-users
Inter-dependencies and constraints due to current and future business processes
Standardisation also helps identify gaps between existing and new value proposition so that they
can be addressed, with as little ambiguity as possible. Gaps categories include:
People Gaps
Infrastructure Gaps
Measurement Gaps
5
This set of parameters is a high level bracket to highlight cost areas
6
The cost of an alternative that must be forgone in order to pursue a certain action.
Business processes should be abstracted as
common ‘enterprise services’ - which can be
switched ‘ON/OFF’ as per business rules. This
lays the foundation of a SOA

14. 14
Tools Gaps
Financial Gaps
This is the first feedback point from ‘Enablers’ axis to stakeholders of the ‘Driver’ axis in terms of
cost and practicality of sustaining the value proposition over a period of time. Investment colours on
the value proposition canvas get more distinct as more details are crytallised on the ‘Enabler’ axis
2.3 Facilitators
‘Facilitators’, third axis of the EC, supports the value propositions and business processes/ functions
defined on the other axes.
Key Stakeholders: Enterprise/ Solution Architects, Operations Managers, Business Analysts,
Business/Systems Analysts, Programmers
Facilitator elements on this axis create the Operating Procedures and Information Technology (OPIT)
framework to align the support model with
business goals. The OPIT elements are:
Facilitator Model
Application Model
Data Model
Integration Model
Infrastructure Model
OPIT Framework helps stakeholders work towards the ‘bigger’ picture rather than focus only on
Information Technology.
2.3.1 Facilitator Model
‘Facilitator’ model is defines the OPIT framework for a new value proposition. Existing OPIT
frameworks and business drivers provide different approaches to define the facilitator model as
given below:
‘Top Down’ Model: When OPIT framework for existing value propositions has little commonality
with requirements for the new value proposition, then a new OPIT framework has to be
developed
‘Reference’ Model: When OPIT framework for existing value propositions have considerable
commonality with requirements for the new value proposition, then the existing OPIT
framework can be used to form a common framework for both value propositions
‘Replication’ Model: When either OP or IT framework elements for existing value propositions
have considerable commonality with requirements for the new value proposition but other
elements are outdated, then use a ‘copy’ of the common elements and develop new elements
for the outdated ones.
The facilitator model adopted should be based on the SOA principles of:
Interoperability
Scalability
Security
Flexibility/ Configurability
Openness
Commonality & Re-Use
The obvious SOA advantage is a substantial decrease in costs for development and testing.
The focus for stakeholders should be to meet (and possibly beat) Business Metrics defined for
Business Processes (on the ‘Enablers’ axis).
Operating Procedures & Information Technology
(OPIT) is:
1. Operating Procedures – Principles to translate
business processes into SOA by design procedures
2. Information Technology – Actual implementation
of SOA using technology
The not-so-obvious SOA advantage is that the
facilitator models can feedback new value propositions
and/ or revenue generating opportunities to the
‘Driver’ axis

15. 15
From a stakeholder view there is no ‘finite’ end-date for a ‘Facilitator’ Model i.e. the model
selected for a value proposition is merely a ‘transition’ towards the larger ‘target’ model which
evolves with newer value propositions. The ‘transition’ is effectively to develop a future-proof OPIT
platform for the value proposition in such a manner that it does not prevent possible future
initiatives.
Hence, from a Total Cost of Ownership (TCO) perspective, the ‘transition’ model should factor in
the following:
Solution Effectiveness
Solution Flexibility (towards the ‘target’ model)
Solution Efficiency
Solution Usability
Solution Performance
Solution ‘Conception-To-Birth’ Time
2.3.2 Application Model
In the body of a facilitator model, an application model forms the vital organs that have specific
functions to perform. The application model owns solutions and deploys IT applications to meet
business requirements
From a stakeholder view, evaluation of applications should be done on the backdrop of business
processes details defined on the Enabler axis. Evaluation parameters include:
I. Business Process Type
Applications can be categorised as per business process types such as:
Execution Process applications: To facilitate day-to-day operations of the enterprise.
These applications should aim to provide granular visibility, control and monitoring
capabilities to measure business performance metrics
Supporting Processes Applications: To facilitate supporting operations to execution
processes across value propositions
Planning Processes Applications: To determine an enterprise’s readiness to respond to
internal initiatives and external factors in future. These applications contain
sophisticated & complex algorithms to ‘predict’ the future
in an optimal way.
Effectiveness of ‘predictions’ is directly
driven by the input to the algorithms.
The input is driven by the integrity of
execution processes. Thus, accuracy
of input to planning applications can propel an enterprise way ahead of its competitors
or add unnecessary weight in its operations to make it crawl.
Often, application vendors attempt to keep the second possibility in the background by
always painting the ideal ‘prediction’ picture.
II. Application Foundation
The application model is based on the foundation of whether the applications are ‘off the shelf’
package applications purchased from the market or developed within the enterprise.
‘Package’ application: These are pre-built and tested applications with generic
functionality addressing one or more Business Functions required by an enterprise. For
example, offerings from IT vendors who
provide package applications for Supply
Chain Execution, Multi- Channel Selling,
Demand Forecasting & Planning, ERP etc.
In case where multiple packages have to be deployed, the best option is to look for
‘suites’ of pre-integrated applications from a few vendors - or if possible a single
vendor.
The ‘future’ aspect in planning applications
has the potential to lock up massive
investments in terms of people, infrastructure
& cash for that time period
For package applications, the challenge is to
fine tune their generic functionality as per
specific business process and integration
requirements

16. 16
‘Greenfield’ application: These are developed specifically for Business requirements of an
enterprise – typically by internal IT or by Software Development/ System Integrators.
Greenfield applications developed on
industry standard architectures such
as J2EE, .Net do provide the initial
groundwork to adopt SOA principles.
III. Solution Based Evaluation: Often, application models definitions are isolated from an overall
solution perspective due to a singular focus on the specific business functions. This leads to an
inappropriate application foundation (Package /Greenfield) for the application model. To prevent
these issues, stakeholders should focus on key solution elements that include:
Core Functionality Fit
Master Data Set Up
Screen Management
Integration Capabilities
Security Access Control
Audit Capabilities
Dependency on other applications
For every solution element, the cost elements for package applications are Configuration and
Modification of the base package. In case of a ‘Greenfield’ application, the cost elements are
design, build (code) and testing.
A critical solution evaluation criterion is the manner in which business requirements are addressed
by a package application and a greenfield application. Typically business requirements are defined
in ‘logical’ modules. For greenfield application the ‘logical’ modules translate into equivalent
solution modules in the application. However, a package application addresses the ‘logical’
modules in terms of data set up, configuration and modifications distributed across the package
platform. Stakeholders should be clear of the distributed solution elements for package
applications as it can have a substantial impact of the cost of the project as we see next.
IV. Total Cost of Ownership: Total Cost of Ownership (TCO) is the sum of cost of designing,
deploying/ building, testing, maintaining and upgrading an application till it is retired. TCO
elements vary depending on the chosen ‘application foundation’ – package or greenfield. Cost
elements for either foundation are same however, the cost value varies significantly depending on
circumstances, as shown in Figure 6
For Greenfield applications, the challenge is in
applying SOA principles to translate business
requirements into flexible & ‘future-proof’
solution. It requires expert design capabilities.

17. 17
‘Expected’ Application Model TCO
0
2
4
6
8
10
12
License
D
esignB
uild/C
onfiguration
Testing
R
unning
C
osts
Upgrade
Cost Elements
CostValues
Package Greenfield
Figure 6 – ‘Expected’ Application Model TCO
Figure 6 illustrates that the total lifecycle cost for a package application (22 units) is
significantly lower than the same for a greenfield application (34 units). The ‘Expected’ TCO
scenario is true for an ideal fit between a package application and business requirements.
‘Misfit’ Package Application TCO
0
2
4
6
8
10
12
License
D
esign
Build/C
onfiguration
Testing
R
unning
C
osts
Upgrade
Cost Elements
CostValues
Package
Greenfield
Figure 7 – ‘Misfit’ Package Application TCO
Figure 7 illustrates that the total lifecycle cost for a package application (39 units) is greater than
the same for a greenfield application (34 units).

18. 18
The higher cost for a misfit package application model case is largely due to lack of ‘Solution
Based’ evaluation by the stakeholders. The root cause, often, is the ‘overselling’ by application
vendors in the evaluation phase.
As a result, in the design/ build phases, the package
is cannibalised to ‘meet’ business requirements. The
‘cannibalisation’ - which can be expensive - is in terms
of complex customization and configuration of the
package application. Instances of modification
(customisation) to the base product are also very frequent. Ideally, the base product should never
be changed – instead modifications/ customisations should be done as services that can be isolated
from the core product for upgrades and maintenance.
2.3.3 Data Model
In the body of a facilitator model, if application model forms the vital organs then data model is
the essential lifeblood that keeps the application model functioning efficiently.
I. Significance
Multiple interaction channels with customers and suppliers make a single view of data entities
extremely important. Typical examples for data entities that need a single view across channels
and lines of business include:
Order information
User Data
Information Access Permissions
Product data
Payment Information across selling / buying channels
Channel proliferation often leads to maintenance of the same data entities split across channel
specific applications. It either is due to ad hoc growth of the application model or due to isolated
solutions for specific business requirements. This situation tends to create data duplication and
redundancy leading to data integrity issues.
Data Integrity issues impact business functions in
in the process execution space due to the potential
incorrectness of information. Similarly the quality of
information fed to planning processes adversely
affects results churned out the planning applications.
For an enterprise, there must be one single data model which provides a common view to all
channels within the enterprise and to customers and suppliers. Depending of the scale of
operations for a value proposition, either all users access data from the same physical data model
or from a ‘master-slave’ data model to cater for localised data requirements. This is the foundation
principle of architecting an optimised data model. In recent times, the concept and practice of
Master Data Management – though not fully mature - is born out of this principle.
A Data Model Framework that provides information to multiple processes and stakeholders, with a
common set of business rules layer for data access, should be used to develop the data model for a
value proposition. Data Model Framework parameters include:
Process(es) : Multiple processes that consume from/ feed to a common data model
Stakeholdesr: Individuals/ Teams who want a relevant information views to be created
from the common data model
Visibility: The capability to provide appropriate details (to processes and stakeholders)
at the right time
Business Rules: The capability to validate and audit data passed to/from the data
model for correctness as per enterprise rules
With data integrity issues, Business Metrics
(KPI) become increasingly difficult to
measure – thus providing a blurred picture
of process efficiency and effectiveness.
‘Customisation Services’ approach
prevents contentious IPR issues
regarding ownership of the base
product code between the enterprise
and the application vendor

19. 19
Format: To standardise the formats in which information records are stored in the data
model
Figure 8 - Data Model Framework
A data model framework is the first step in creating a ‘golden’ repository of information that can
ensure the ‘correctness’ of information being passed to the execution and planning process of the
value proposition.
The ‘correctness’ is driven by how an industry works.
Industry associations7
– which are made up of leading
industry organizations – work towards standardising
the way the industry works. Some of these associations
have formal data modeling standards which can be leveraged to start with. For examples, ARTS
data model for the retail industry is continually updated by the Association for Retail Technology
Standards (ARTS)
II. Benefits
A common and clean data model has the potential to benefit an enterprise across business
processes and stakeholder hierarchies. Frequently addressed industry ‘pain-points’ have a strong
resolution in the form of a ‘clean’ data model. For example,
Enterprises can save significant costs by reducing data entry effort and error reconciliation due
to a single point of maintenance
Reduced ‘time-to-market’ (TTM) for new value propositions due to simple master data set up
Cost effective and automated transaction updates via collaboration via external fulfillment
partners
7
ARTS (Retail), ETSI (Telecommunications), ITMA (Transportation & Logistics), ABPI Pharmaceutical), EECA (Electronic
Component Mfg), AAFA (Footwear & Apparel)
“One version of truth” established by the
master data repository helps ensure data
accuracy to aid both operations and
decision making

20. 20
Provide better customer service by maintaining consistent data across the organization thus
having “One face to the customer”
Increase sales by improving quality of forecasts and demand generation results that increase in-
stock and fill rate
A clean data model lays the foundation builds inherent flexibility to the enterprise to support
standards like GTIN, RFID and adapt to changes
The single point of maintenance makes it easier to reconcile data due to external influences
such as Government regulations, environmental policies etc
2.3.4 Integration Model
In the body of a facilitator model, if application model forms the vital organs and data model is
the essential lifeblood, then integration model is the network of veins and arteries which
seamlessly transport the lifeblood to vital organs.
The Integration Model transports data across applications and user to create a seamless information
channel for an enterprise. It is also termed as Enterprise Application Integration (EAI) model. An
integration model can be classified into two groups:
Extended EAI (xEAI): To create the information
channel between an enterprise and external actors
such as suppliers, manufacturers, logistics
partners, enterprises, 3 Party warehouses, distributors,
customers, consumers etc
Internal EAI (iEAI): To create the information channel
between applications within to support multiple
channels and value propositions.
Figure 9 - Integration Model
The foundation for ‘collaborative’
business model is based on the xEAI
and iEAI models. It enables seamless
interaction models such as B2B, B2C
and A2A, irrespective of the industry
verticals

21. 21
Lack of basic integration models breeds a number of common ‘pain points’ across industries.
For example, invoice reconciliation, manual data entry into multiple systems for a single order,
order reconciliation based on external updates, inventory mismatch due to disparate
applications, incorrect asset accounting, lack of order visibility leading to customer
dissatisfaction, multiple product views to customer across different channels, ad hoc reporting
functionality etc.
The root cause in the above examples is an absence of a common entity that ‘owns’ the
complete lifecycle of the transaction. Often, the reason is the unique references used by each
internal and external application involved in processing the same transaction. It necessitates a
reconciliation of the unique ‘references’ across applications. In absence of common information
channel to connect these applications, manual effort for reconciliation is the visibly significant
problem for business users. Thus, an absence of a working integration model to connect internal
and external enterprise applications diverts the focus of business stakeholders from improving
processes effectiveness to data reconciliation.
To create a basic seamless information channel between external and internal enterprise
applications, an Integration Model should be defined on three basic principles:
Data Format: To provide an application agnostic data bus for any data format. For example:
- XML, CSV, Flat File, EDI etc.
Data Transport & Access Mechanism: To provide an application agnostic data movement
channel to enable communication between enterprise applications. For example :- Http(s),
Web services, MQ, JMS, FTP, TP-UNIX etc
Security Mechanism: To maintain integrity of data being moved between applications. For
example:- Encryption, LDAP etc
Each principle plays a critical role in isolating applications/systems functionality from
integration requirements by creating a universal ‘envelope’ that can be understood by
applications within and beyond the enterprise. The ‘envelope’ effectively transports data
across the enterprise with minimal modifications to functional applications.
Additional features that can enhance the basic capabilities of an integration model are:
Data validation
Data Enrichment
Data Aggregation from multiple source applications
Data disaggregation to multiple recipient applications
Data broadcasting / multi casting
Effectively, an integration model should aim for a ‘full intermeshed’ framework that resides
between all enterprise applications for seamless communication instead of a non-scalable,
complicated and expensive ‘point-to-point’ communication network.
A good Integration model has massive potential to improve operational efficiency and
effectiveness of an enterprise. It benefits business operations by:
Eliminating duplication of effort to synchronise multiple systems
Reducing error rates resulting in:
o Lower Error reconciliation cost
o Lesser customer ‘churn’ because of error ‘re-processing’ ability
Shorter ‘order to cash’ cycle times
Reduction in overall working capital
Increased automation resulting in lower expenses such as additional resources, office space,
equipment
Timely and high quality data availability across the for better decision making

22. 22
2.3.5 Infrastructure Model
In the body of a facilitator model if application model forms the vital organs, data model is the
lifeblood and integration model is the network of blood vessels, then infrastructure model is the
actual muscle and bone power
I. Business Expectations
An Infrastructure Model consists of:
Operations Infrastructure: Office Spaces, Warehouses, Staging Depots, Transportation
Fleet, Maintenance Workshops, Employee Facilities etc constitute the Operations (OP)
infrastructure elements of the Infrastructure Model
For an enterprise to create an operations infrastructure, two broad options are whether
to build it internally or to leverage expertise of 3rd
parties by outsourcing. These
decisions are directly linked to the Business Metrics which are based on investment
decisions. Stakeholders should use business processes and functional details to evaluate
each Operations Infrastructure element to make the decision
Information Technology Infrastructure: Deploying IT hardware, installing the
software, connecting the hardware and configuring the software constitute the
Information Technology (IT) elements of the Infrastructure Model. It encompasses:
i. Soft Building Blocks
1. Operating Systems: UNIX, Linux, Windows
2. Database Systems: Oracle, MSSQL, DB2
3. Applications: Functional, Integration, Performance Management,
Common
4. Network :Topology
ii. Hard Building Blocks
1. Servers: Database, Application, Shared Services, System Management
2. End User Devices: Browsers, PDAs, RFID tools
3. Network Components: Routers, Switches, Cables
Figure 10 - Infrastructure Model

23. 23
Business Expectations should be evaluated and analysed to segregate ‘essential’ and ‘nice-to-
have’ expectations. Evaluation and analysis parameters
broadly can be classified into:
Complexity of Business Processes i.e.
‘Do alternatives/ ‘work-arounds’ exist?
Business Impact of Downtime in terms of
lost sales, expediting ‘stuck’ transactions
and reconciliation of ‘errored’ transactions
Technology Impact in recovery and restoration to the working state
II. Decision Factors8
Based on the evaluation and analysis, stakeholders need to decide on the immediate and on-going
costs to creating and maintaining the infrastructure model. The two major decision areas are as
given below.
Defining Specifications
IT hardware specifications drive the initial direct costs for an IT infrastructure model. Common
evaluation criteria are:
o Type of hardware: The impact is on the initial investment to buy the product.
Typically hardware vendors provide options in the High End, Medium, Low End
categories
o Application Characteristics: Type of Application (Execution, Supporting, and
Planning), Expected Data Volume, No of Users, and Concurrency of applications /
users logged-in etc. This directly drives the type of hardware to be used i.e. start of
with High End or start with medium/low end hardware and scale up as required
o Integration Characteristics: Number of intra-enterprise / inter- enterprise
connections. This directly impacts the costs associated with hardware to power the
integration model
The exercise to define hardware specifications has to be finely balanced between being too
fastidious up to the last user to be counted and being too optimistic about the hardware
capabilities. The impact of hardware specifications can bring the business to a grinding halt if
underestimated or it can lock up huge investments without a desirable ROI, if overestimated.
Deployment Approach
The deployment approach provides an estimate for on-going direct costs for an IT infrastructure
model in terms of maintenance and upgrade services. There are different ways to adopt a
deployment approach.
o Traditional Deployment
IT solutions from Application, Data & Integration models are deployed separately on
discrete physical ‘boxes’ of hardware in one or more locations. The Infrastructural
elements (‘boxes’) – hardware & software - are owned, controlled and managed by the
enterprise internally. This requires a committed headcount and consulting resources
within the enterprise. The cost of managing the infrastructure model has to be factored
in the budgeted plans for the value proposition.
o Virtual Environment
IT solutions from Application, Data & Integration models are deployed on a single
machine9
to create a ‘virtual’ environment which can be shared across multiple
locations. This enables providing business solution functionality crossing physical and
geographical limitations over multiple operating systems and multiple applications.
8
This section will focus on evaluation parameters for Information Technology infrastructural elements
9
For virtual environments, the hardware sizing may vary significantly from the traditional deployment approach
Business Expectations
Availability, Security, Scalability,
Manageability, Reliability, Supportability,
Repeatability, Standardization, Integration

24. 24
o SaaS
With new approaches such as Software as a Service (SaaS) – which is also called ‘On
Demand’ - the entire responsibility of deployment, support and maintenance is owned
by application/ technology vendors. All that an enterprise needs to maintain is good old
Ethernet cable and wireless hub (in case of wireless LANs).
Recently SaaS pioneers have introduced the concept of Platform as a Service (PaaS).
From an enterprise perspective it means they can take ready-made components such as
database, authentication process, and single log-in and use them in their applications.
In a way it compares the transition that Microsoft made when it moved from supplying
desktop applications to the Windows platform and the tools that went with it.
To decide which deployment model to adopt for a for a value proposition, an enterprise needs
to look at the scope, scale, criticality and time to deploy. The ideal corporate philosophy of
viewing the business as a unified whole applies, especially, to the deployment approach for
infrastructure model. Enterprises should evaluate the potential for energy savings and lower
capital expenses due to more efficient use of hardware resources. Also on-going costs for
maintenance, security management and disaster recovery play an important role in deciding the
deployment model.
Enterprises must look to leverage the upside potential of these approaches, rather than see
them as a threat to their existing modus operandi.

25. 25
3 Conclusion
For enterprise stakeholders, the challenging question is: How and when do the three axes of the
Enterprise Cube evolve from a time perspective? Are they strictly sequential i.e. Driver Enabler
Facilitator? Or do they evolve in parallel?
As we have seen the each axis feeds information to the other two – although with different
weightage. The figure below depicts that Business Drivers lead the way for Enablers and
Facilitators. However, the ‘Closed Loop’ from Enablers & Facilitators to the Drivers provide the
necessary feedback to navigate towards a maximizing the ROI for the enterprise. The feedback
keeps helps all stakeholders have a common focus.
Figure 11 - Enterprise Cube Evolution
Information Technology elements play an active role in conjunction with the business process
definitions on the ‘Enabler’ axis. The simple reason being, unless the processes are worked out
efficiently, it will be unclear where Information Technology will facilitate to support it. Else it
becomes a an exercise of facilitating an inefficient process model – which gets unmanageable
and difficult to reconcile as its adds more complexity.
For an organization to build its own ‘Enterprise Cube’, elements along the three axes can be
adapted to suit specifics its business model. For example, KPIs on the ‘Enabler’ axis although
benchmarked against industry standards will always be defined by enterprise stakeholders
based its existing operations. Similarly, evaluation criteria for the feasibility parameters on
‘Business Drivers’ axis are often controlled by the corporate strategy for an enterprise.
This white paper is based on generic enterprise behavior across industries. It is prescriptive
rather than being definitive.

26. 26
Acronym Key
A2A – Application to Application
AAFA – America Apparel and Footwear Market
ABPI - Association of the British Pharmaceutical Industry
ARTS – Association for Retail Technology Standards
B2B – Business to Business
B2C – Business to Consumer
COGS – Cost of Goods Sold
CSV – Comma Separated Value
EC - Enterprise Cube
EDI – Electronic Data Interchange
EECA – European Electronic Component (Manufacturers’) Association
ETSI – European Telecommunications Standards Institute
FTP – File Transfer Protocol
iEAI – Internal Enterprise Application Integration
IPR – Intellectual Property Rights
IT – Information Technology
ITMA – International transport Management Association
JMS – Java Messaging Service
KPI – Key Performance Indicator
KRA – Key Result Area
LDAP – Lightweight Directory Access Protocol
MQ – Message Queue
NPV – Net Present Value
OPIT – Operational Procedures and Information Technology
P&L – Profit and Loss
PaaS – Platform as a Service
PDA – Personal Digital Application/ Assistant
PoS – Point of Sale
RFID – Radio frequency Identification
ROA – Return on Assets
ROCE – Return on Capital Employed
ROI – Return on Investment
SaaS – Software as a Service
SOA - Service Oriented Architecture
TCO – Total Cost of Ownership
TELCO - Telecommunication
TPS – Toyota Product Systems
TP-UNIX – Transaction Processing in UNIX
TTM – Time to Market
WMS – warehouse Management System
xEAI – Extended Enterprise Application Integration
XML – Extensible Mark up Language

27. 27
References
1. ‘The Rise and Fall of Marks & Spencer’ – Judi Bevan, Profile Books Publication, 2007
2. ‘The Toyota Way’ – Jeffrey K. Liker, Tata McGraw Hill, 2004
3. ‘The Age of Turbulence’ – Alan Greenspan, Penguin Publications, 2007
4. ‘The Open Group Architecture Framework (TOGAF)’, Version 8.1.1
5. Measuring IT Infrastructure Project Size: Infrastructure Effort Points - Joost Schalken, Sjaak
Brinkkemper, and Hans van Vliet, 2005
6. IT Infrastructure Architecture Building Blocks - Ramesh Radhakrishnan, Sun Professional
Services, Rakesh Radhakrishnan, Sun Professional Services, 2004
7. CIES Annual Outlook, 2007
8. ‘Comparing Multi-Core Processors for Server Virtualization’ - Robert E. Carpenter, Intel
Corporation, August 2007
9. ‘Industry logical data models - Are they right for your enterprise?’ - Steve Hoberman,Teradata
Magazine, December 2006
10. ‘Business Logistics/ Supply Chain Management’– Ronald H. Ballou, Pearson Education, 2004
11. ‘Telecommunication Essentials’– Lillian Goleniewski, Addison Wesley, 2006
12. ‘ARTS Data Model Committee Retail Data Model Scope’ – ARTS, Release 5.0, 2005
13. Supply Chain Operations Reference Model 8.0 - Supply Chain Council, 2006
About the Author
Sudhir Nilekar is the Director of Enterprise Cube Consulting, UK. He works as an independent consultant
for business process re-engineering, strategy formulation and IT enabling to customers. He has over 10
years of experience in consulting, solutions architecture delivery, and pre-sales and as an end user in the
retail, logistics & distribution and manufacturing industry.
Copyrights and Trademarks
Copyright - 2008 Sudhir Nilekar
All Rights Reserved. This material is subject to copyright protection
No part of this document may be reproduced in any form by any means without prior written
authorization of Sudhir Nilekar
Send comments and suggestions to Sudhir_Nilekar@gmail.com