While
every organization’s budgeting and capital planning
process is different, and the Enterprise Architecture
integration with these processes will vary,
there are several critical success factors associated
with a successful Enterprise Architecture Program
implementation.
The
next figure outlines IFEAD’s view on the relationships
among Enterprise Architecture, Enterprise Program
Management, Solution Architectures, and the
Budgeting Process integrating into the overall
EA Validation, Program & Measurement Process.
4.2.1
Using
Business Behaviour instead of Business Processes
as part of the EA Framework
Most
EA frameworks have business processes as an element
of the enterprise architecture, when in fact a
business process as an organizational entity typically
has more to do with the decomposition of functions,
or the needs of structuring the organisation,
then it has to do with modern enterprise architecture.
Using business processes as an organizing entity
in enterprise architecture will most likely lead
to inflexibility and fixed structures. Do you
recognise the quick implementation of fixed inflexible
business processes in ERP systems. It’s like a
foundation of reinforced concrete.So instead
of addressing traditional well described business
processes it is better to focus on what is called
business behaviour when dealing with enterprise
architecture.
4.2.1.1
Business Behaviour
Business
behaviour (BB) is an ordering of tasks and/or
activities that accomplish business goals and
satisfy business commitments. It may include
manual or automated operations that complete
units of work.
Behaviour
manipulates various resources in the business
in order to produce the desired result, and
resources of all kinds enable it.
Business
behaviour is quite recursive, although various
reasons and methods for imposing specific structure
on aspects of business behaviour can be discussed.
4.2.2
Using
Solution Sets instead
of Information Systems itself as part of the
E2A Framework
Using
information-systems itself as an organizing
entity in enterprise architecture will most
likely lead to misalignment. The aspect area
of Information-Systems Architecture is useful;
however don’t refer to applications itself rather
then to solution sets that can be supported
by information-systems.
As
illustrated next, a properly described solution-driven
approach, which abstracts from the business
behaviour design the function and feature requirements
for this behaviour into “solution sets”. This
will result in much better alignment and will
reduce inefficiencies from gaps and overlaps
that result from a more typical application
centric approach.
4.2.2
Using Solution Sets instead of Information Systems
itself as part of the E2A Framework
A
Solution Set contains a description of the common
required functions and features required by
the tasks / activities of different business
areas it supports. Translating those functions and features into IS solution areas
and IS services / applications determine gaps
and overlaps within existing or future products,
will help the organisation in defining the best
IT solution support.
A
successful Enterprise Architecture provides
a mechanism for mapping business drivers to
significant architectural solution areas that
make up the overall enterprise model of the
future state.
That mapping should eliminate any ambiguity
that exists about the reason for implementing
that solution.
The alignment also will provide the basic
construct for building the business case for
the solutions justification.
Building the business case for an architectural
solution area requires that that solution can
be mapped to a business or organizational driver,
and that its benefits, cost, risks, and interdependencies
can be quantified.
A
business solution set is a part of the overall
framework that is significant enough in itself
to be considered from a design, costing or implementation
standpoint. Decomposing the enterprise architecture
into business solutions is key to enabling the
analysis process.
It allows for multidiscipline teams to
iteratively work together creating an enterprise
view, while at the same time, dispersing into
discipline specific teams performing detailed
analysis and validation.
4.3
EA Measurement Process
4.3.1
Value
Net Based Assessment
Interrelationship
among the solution sets can be maintained using
cross-reference models, tables and matrices.
Those matrices must properly allocate
the benefit, cost and risk contributions of
each enterprise architectural solution.
The logical way of doing this
is to organize the various disciplined business
or EA solution sets in conformance with their
position in the value net.
4.3.2 Measurement and Valuation
Each
enterprise architectural solution sets must
include metrics for evaluating its contribution
and cost to the overall enterprise value net. Both quantitative and qualitative benefits
and cost metrics can be captured for each discrete
solution or product and their contributions
to the value net allocated.
In
the next example, IS Services / application
costs are allocated at both the Solution Set
level and at the Task / Activity level.
Cost would be allocated at a Task / Activity
level when those Task / Activities have serious
cost impacts on there own, and need to be evaluated
separately.
An
Enterprise Architecture that uses solution sets
and normalization to analyze business needs
and IT opportunities allows the development
of a neutral cost / risk analysis.
This cost / risk analysis allows you
to understand how brittle or adaptive your chosen
transformation will be.
4.3.4
Effective
Deployment via Enterprise Program Management
A
major predictor of the extent to which enterprise
architecture influences the actual business
& IT asset base is the quality of the transformation
plan. The
plan factors in the competing forces impacting
transformation, which typically include:
1.
Potential ROI;
2. New opportunities provided by recently developed
technology enablers;
3. Organizational and budgetary constraints;
4. The need to amortize existing and ongoing
business & IT investments;
5. Maturity of the organisation and the capabilities
of the people;
6. Maturity of technological alternatives and
other implementation related risk factors.
Many
of the Enterprise Architecture Frameworks that
are gaining currency today very much resemble
the early phases, and, in some cases, the later
phases, of a software development life cycle.
This leads to a fair amount of unnecessary
work and a loss of focus, as the level of specificity
goes way beyond what is required at the Enterprise
Architecture level.
4.3.6
Expected
results from an Enterprise Architecture Program
The
ultimate operational goal of any organization
is to optimise the alignment of their customer
& partner needs, business strategy, organizational
culture, business, people, processes and technology.
This optimisation, not only provides
for efficient and cost effective performance,
but also helps ensure proper execution of the
defined organizational goals and objectives.
The
table below provides a maturity model for the
implementation of the Enterprise Architecture
Program that can help organisations to identify
the level off roll out of their Enterprise Architecture
program.
5
Today’s
Practice
Both
industry and government all over the world have
recognized the special value of Enterprise Architecture.
Industry
has been motivated by the simple reality that
they need Enterprise Architectures to remain
competitive and support business continuity
as they consolidate their long spending efforts
on disparate IT resources.
While
this is a positive move, a fundamental problem
remains. In the rush to implement Enterprise
Architectures, most current frameworks and methods
are in need of updating to address today's realities.
The
virtual plethora of options and overlapping
products and standards, and the focus on package
integration, create a much more complex environment
then the environment that most of these frameworks
and processes were designed to address. Most
frameworks are focused on providing detailed
modelling of systems and activities that are
only moderately relevant at the enterprise level.
Many of these descriptive models and frameworks
have their pedigree in the systems engineering
arena, and so much of what is prescribed is
more suitably addressed in either domain specific
solution architectures or software design efforts.
This
level of detail in the Enterprise Architecting
effort can be a significant impediment to engaging
the stakeholders effectively in the enterprise
architecture team.
Finally,
while most Enterprise Architecture frameworks
and processes do a fairly good job at providing
a means for describing current and future state
enterprise architectures, and typically prescribe
significant participation from key stakeholders
in the effort, they do not effectively address
the enterprise value net, alignment, traceability,
performance measurement and the need for extended
enterprise architectures that are actionable.
1.
'Maturity model for the implementation of Enterprise
Architecture Activities', Schekkerman Jaap,
Published IFEAD, 2004.
2. Antoine de Saint-Exupery; http://www.thinkexist.com/English/Author/x/Author_1147_3.htm
3. IFEAD, Enterprise Architecture Survey 2003,
http://www.enterprise-architecture.info
4. Gartner Inc.; http://www3.gartner.com/Init
5. The Open Group; http://www.opengroup.org/
6. Book 'How to survive in the jungle of Enterprise
Architecture Frameworks'; Schekkerman Jaap,
will be published November 2003.
7. 'Good is good enough' see ref. 2
8. 'A Standard for Business Architecture description'
McDavid D.W., published in IBM Systems Journal
1999.
9. 'Solution Sets'; White Paper, Interoperability
Clearing House, USA, 2002.
10. Book 'Architectuur, besturingssysteem voor
adaptieve organisaties' Rijsenbrij, Schekkerman,
Hendrick, Publisher Lemma, 2002.
11. Refined and combined version of the Meta
Group "Enterprise Process Maturity Model"
