Extreme Enterprise Architecture Planning (XEAP)
Extrapolating Agile Characteristics to the Development of Enterprise Architectures
Hugo Ramos and André Vasconcelos
Instituto
Superior Técnico, Universidade de Lisboa, Avenida Rovisco Pais, Lisboa, Portugal
INOV – Inesc Inovação, Rua Alves Redol, 9, Lisboa, Portugal
Keywords: Enterprise Architecture, Software Development, Extreme Programming, Scrum, Enterprise Architecture
Planning, TOGAF ADM, Methodology, Reference Model, Agile, Cycles, Iterations, Partitioning, Business
Model, Macro-Processes, Processes, Sub-Processes.
Abstract: When developing enterprise architectures, in the same way as software products, companies have to deal a
constant growth on the clients demand for faster results, while facing, at the same time, a big uncertainty on
the requirements surrounding the project. This paper tries to investigate the similarities between the
difficulties faced in both industries of enterprise architecture (EA) and software development, and propose
an extension to an existent EA development methodology, in order to address those difficulties using
particular agile software development methodologies characteristics. This new extension tries to introduce
agile characteristics such as several iterations, solution partitioning and constant client feedback in order to
deliver faster results and have a bigger capacity of response to the change of requirements, when compared
with the standard methodologies. To do so, the first iteration is based on a reference model and the next
ones follow the Enterprise Architecture Planning (EAP) methodology steps and are adaptable to the
business itself. After presenting our proposal we make the demonstration of the methodology developed,
applying it to a real-world problem of local organization called Cascais Ambiente, responsible for the
maintenance of the environmental health in Cascais city.
1 INTRODUCTION
Nowadays all enterprises, ones more than others,
face big difficulties that come from their
surrounding environments. With relentless
competition in almost all sectors, comes the increase
of new offers, substitute and competitor products
and consequently the growing necessity for faster
results while constantly facing uncertain
requirements.
Software development industry is a particular
example of an area where those problems had
always been quite obvious. Natural, he companies
started felling the necessity to use new and
innovative ways of developing their products, once
the traditional and standard ones were not able to
answer the market expectations that were increasing
in a really fast way. Those necessities were fulfilled
by the introduction of the called “agile software
development methodologies”, such as Extreme
Programming (XP) and Scrum. Both Scrum and XP,
are based on the motivation to deliver fast results to
the client in an incremental and partitioned way
while having an inside-costumer involved on the
process in order to have a constant feedback,
allowing to easily overcome the requirements
uncertainty that are typical in such projects.
When observing closely, we can identify some
similarities between the needs of both software
development and enterprise architectures
development industries, expectedly concerning the
client’s needs for faster results while having a big
requirements uncertainty originated by the
surrounding environment. With the similarity
between needs and the success achieved by the agile
approaches on the fulfilment of those needs in the
software industry, we intend to extrapolate some of
the main agile characteristics of those approaches
into a well-known traditional enterprise architecture
development methodology, in order to overcome the
demands described above.
Our proposal will be based on EAP methodology
of Steven Spewak (Spewak, S. and Hill, S., 1992), to
which we intend to make some “agile” changes,
376
Ramos H. and Vasconcelos A..
Extreme Enterprise Architecture Planning (XEAP) - Extrapolating Agile Characteristics to the Development of Enterprise Architectures.
DOI: 10.5220/0004890503760383
In Proceedings of the 16th International Conference on Enterprise Information Systems (ICEIS-2014), pages 376-383
ISBN: 978-989-758-029-1
Copyright
c
2014 SCITEPRESS (Science and Technology Publications, Lda.)
transforming it into an iterative process, while
introducing characteristics such as solution
partitioning and constant client feedback, with the
clear objectives of reaching a methodology capable
of deliver faster results to the clients, while dealing
with a big requirements uncertainty (when compared
with the standard methodologies).
2 PROBLEM
The uncertain environment which the enterprises
face nowadays, are closely connected with the
clients own changing requirements and visions of
the business. Not surprisingly, maintaining control
over the requirements process is nearly impossible
as each customer group pushes for its own interests
and the changing technologies lure customers into
escalating demands (Brooks, JoAnn M. and all,
2008).
The surrounding environments and the
competitiveness of the markets originate enormous
difficulties when trying to clearly define
requirements, making the development of enterprise
architectures an even more difficult process. Not
rarely, this problem leads projects into a two way
path, where either the project continues its normal
pace, keeps all the original plans ignoring the
changing environment and requirements ending in a
completely failed project unable to achieve the
expected results, either it tries to answer in an
appropriate way to the changes and uncertainty of
the requirements and ends up completely failing the
predicted and agreed time schedule and/or budget.
Alongside with this uncertain environment it is
the organizations increasing needs and expectations
for shorter cycles with production of return, as well
as faster results (Spewak, S. and Tiemann, M.,
2006). The constant changing environment and
relentless competition that enterprises face today
brings them a high necessity for fast results in all the
areas evolving the business in order to adapt and
create new opportunities (Land, Martin O., and all,
2009).
Some years ago, the problems identified above
(environment uncertainty and demand for faster
results), were deeply evident on the software
development industry, while this started being one
of the most competitive and fast-growing industries.
At this time started being globally recognized the
urgent need for efficient methods and practices
capable of facing the recognized demands. As an
attempt to answer those demands, the notion of agile
approaches started rising, where instead of
developing software as a big complex and flat
process ending in a big delivery, it would be done in
an iterative way with several small deliveries in
order to embrace and manage the possible changes
that may happen along the process, while dividing a
big problem into smaller ones (Sommerville, I,
2010).
Analysing in a more particular way, the projects
of enterprise architecture development are not
different from the generality and in this case there
are some problems that with the growing of the
companies had become more and more difficult to
deal which reclaim for a methodology capable of
dealing with those problems in the same way agile
approaches did on the software development
projects.
Quite often in EA projects, the clients find
themselves obligated to choose from their business
functions, the ones that must be actually considered
on the architecture. Other functions that may also be
important and critical end up being left behind, due
to the limited amount of time allocated to the
completion of the project (Townsend, J., and all,
2008). Those cases show us that we can achieve a
level of independency between systems, capable of
being explored in a way that delivering the results of
different systems separately and in several iterations
becomes a requirement and success factor instead of
an obligation due to the tight schedules or
complexity of the project.
As a way to summarize our problem we present
the questions that we try to answer with our work:
Are the demands for ability to support uncertain
environments and delivery of fast results, in
Enterprise Architecture, achievable by
extrapolating Agile Software Development
approaches characteristics?
Are process iterations, small releases and
continuous client feedback the correct
characteristics able to achieve faster
results and
bigger response capacity to changing
requirements?
Is a standard and traditional enterprise
architecture methodology capable of “accepting”
the introduction of agile characteristics
?
3 RELATED WORK
3.1 Agile Software Development
Agile Software Development appeared has an
answer to the fast changing, uncertain and
unpredictable environments that surrounded the
ExtremeEnterpriseArchitecturePlanning(XEAP)-ExtrapolatingAgileCharacteristicstotheDevelopmentofEnterprise
Architectures
377
projects of software development. These
environments include client uncertain requirements,
new target markets, substitute and competitor
products/services and even economic changes. With
all the difficulties, this competitive and restless
industry started demanding for methodologies
capable of delivering fast results, once this started
emerging as the main requirement of the clients,
leaving behind important requirements like software
quality (Sommerville, I., 2010).
The most famous and used agile methodologies
are Scrum (Schwaber, K., 1995) and Extreme
Programming (Beck, K., 1999), which introduced
some new concepts and characteristics to the
software development process. From those
characteristics we can highlight the introduction of
iterations with releases and deliverables to the client
at each one of them, the constant client feedback
with a huge involvement in the project and the short-
term goals over the long-term ones.
3.2 Enterprise Architecture
Enterprise architecture can be described as a
governance and decision making instrument with the
capacity to fulfil the gap between enterprise’s vision,
strategy, and change projects. Enterprise architecture
tries to deal with this gap, by achieving a common,
shared and unanimous comprehension about what
are the company structure, business model and the
necessary systems to support that model (Land,
Martin O., and all, 2009).
Some of the most used enterprise architecture
development methodologies are Enterprise
Architecture Planning (Spewak, S. and Hill, S.,
1992) and TOGAF ADM (The Open Group, 2009).
EAP is an older methodology especially focused on
the information systems and that does not go further
than the planning of the “TO-BE” state of the client.
Contrarily, ADM is a wider methodology, not only
capable of planning all the enterprise architecture,
but also with concerning on the actual
implementation process and its governance as well
as on the change management. Being an overall
simpler and shorter methodology, EAP constitutes a
more suitable process for our purposes of adding
some new agile characteristics, and therefore is the
basis for our proposal and the general steps
involved.
3.3 Reference Models
Reference models are prototypes of some
application domain. Those models intend to reduce
significantly the trouble inherent to the creation of
application-specific systems, where we can select
the more important parts of the model and adapt
them to a specific problem. When applicable, this
possibility gives us a huge advantage in terms of
both cost and time saving, on the development of the
projects (Ramesh, B. and Jarke, M., 1999).
On our work in particular, we will use the
reference models with the clear objective of
presenting results to the client as soon as possible,
through the delivery of a first high-level architecture
based on one specific model, considered suitable for
our project, once this models can be used as a
starting point to construct project-specific models
(Becker, J., and all, 2007).
4 PROPOSAL
Our proposal consists on extrapolating some
characteristics of the agile approaches used in
software development, as Extreme Programming
and Scrum, to the domain of the enterprise
architecture. We will base our process on the
Enterprise Architecture Planning (EAP)
methodology where we will introduce agile
characteristics.
We will give special attention to the inclusion of
several iterations in the process, as a way to
transform a slow, big and complex process into
several sequenced simpler iterations while exploring
the possible independence between components of
the solution, which in this case are the information
systems that support different business functions.
Figure 1: Extreme Enterprise Architecture Planning.
ICEIS2014-16thInternationalConferenceonEnterpriseInformationSystems
378
4.1 Differences/New Characteristics
4.1.1 Step-by-Step Process
First Iteration
In the first iteration we will have the first contact
with the client and the business. One of the main
goals of our proposal is to deliver results as fast as
possible. As a way to accelerate the process without
losing accuracy, we adopted and adapted a business
reference model to our specific client. With this first
architecture we will give the client a high-level view
of what their architecture should look like, and
which systems are the more suitable to support their
business.
Business Macro-processes Model
In this first step we present a reference model
containing macro-processes considered suitable for
the type of business we are dealing with, relating
them with the main information entities that we are
able to identify through a simple analysis of general
information.
Data Architecture
After identifying the more important information
entities on the previous step, we must do a data
architecture capable of describing in a first high-
level the relation between those entities and their
characteristics showing the structure that is achieved
when relating all of them.
Applications Architecture
By relating the reference macro-processes and
information entities identified in the first step, we
are now able to understand which applications
should be supporting the model described. As a
result of this step, we are able to provide to the
client, since the very first meeting, a description of
the applications and systems he must have,
representing an ideal “TO-BE” state and a difficult,
but clear objective for the future.
Second Iteration
On the second iteration we start performing a
complete cycle of EAP process, purposely missing
the last step of implementation/migration plan,
which we will do only once in the end of the last
iteration.
Values & Principles
This step defines the basis for the EA and for all its
future decisions. This phase is performed only on
this second iteration, once it defines values and
principles that must be followed during the rest of
the process.
Business Processes Model
This step marks the beginning of the organization
“AS-IS” state definition. Firstly we will need to
identify and relate the processes of the business and
the information entities used by those processes in
order to achieve an accurate model of their reality.
Current Systems & Technology
This step completes the definition of the present
state of the company. This phase is not only
important to define which systems the client have in
the present, but also to help us understanding what
we can or cannot have in the future, once will give
us the possibility to do a later evaluation of the
impact that the architected systems and technologies
will have on the current ones.
Data Architecture
With the information entities identified before, we
are able to formulate a data architecture that shows
how those entities must be connected and structured
in order to have the most efficiency possible when
manipulating the data that supports the business.
Applications Architecture
Through the understanding of how the business
processes use each information entity, we are able to
formulate and present a first group of candidate
applications, which together can effectively support
the organization activity. The result of this step is
achieved using a CRUD matrix.
Technology Architecture
After defining the more suitable applications for the
business we must define the technology that will
support those applications. Having into account that
we are already on the second iteration, we will have
to understand how the existing technology can or
cannot handle those applications and what are the
necessities, if any, of the organization in terms of
technology infrastructure.
Third Iteration
The third iteration is in every way similar to the
second one. The main difference between them lies
on the business processes level of detail. On the
third iteration we will decompose the previous
processes into sub-processes and find some more
information entities that they may use, going even
deeper on the clients business model.
Business Sub-processes Model
On this step of the third iteration we will start
redefining the “AS-IS” state of the organization,
now with some detail about their processes and
information entities. We can now decompose the
processes identified on the previous iteration into
ExtremeEnterpriseArchitecturePlanning(XEAP)-ExtrapolatingAgileCharacteristicstotheDevelopmentofEnterprise
Architectures
379
sub-processes and therefore identity new
information entities.
Current Systems & Technology
On this particular step we identify the systems that
support the business sub-processes and information
entities identified. Having into account that we are
on the last iteration, we expect to have identified the
complete set of systems that the organization
currently use.
Data Architecture
This step corresponds to the final data architecture,
representing the necessary and more suitable
structure of the complete set of information
supporting the business.
Application Architecture
This step corresponds to the final applications
architecture. The relation between the most detailed
sub-processes and all the information entities of the
business will allow us to identify the final set of
applications capable of supporting the complete
organization activity.
Technology Architecture
On this step we will finish our architecture definition
with the presentation of the technology capable of
supporting the applications identified on the
previous step.
Implementation/Migration Plan
Finishing our methodology and the project is the
Implementation/Migration plan, where we make a
planning of the systems that need to be implemented
and installed, where we include effort, resources and
benefits estimates, alongside with an impact analysis
on the current systems.
5 CASE STUDY
In order to demonstrate our proposed solution, we
applied our artefact to a real-world problem form a
local organization called Cascais Ambiente.
5.1 Applying the Methodology
First Iteration
Business macro-processes model
In order to achieve a preliminary business model we
relate the macro-processes, based on the PCF
reference model (APQC, 2012.) chosen for this
specific project, with the information entities that are
common to almost all businesses in general and are
suitable to this one in particular.
Figure 2: Relations between business macro-processes and
information entities on the first iteration.
Data Architecture
On this step we relate all the data entities identified
before. We are now able to provide a general view
of the data structure that is more suitable for the
business with special attention to the information
being shared by more than one entity.
Figure 3: First iteration relations between information
entities.
Application Architecture
The CRUD matrix provides us an understanding of
the applications capable of supporting the client
activity in the most effective and sustainable way
possible. During this process we must keep in mind
that we are working with a reference model, and
therefore, we are presenting an ideal situation to the
client of how his IS architecture should look like,
and not yet representing is actual situation, which
will be addressed later on.
ICEIS2014-16thInternationalConferenceonEnterpriseInformationSystems
380
Figure 4: First iteration CRUD matrix.
Second iteration
Values & principles
The project will have the maximum duration of 3
months. In agreement with the client, was decided
that this work would start by addressing only the
Operational side of the business, once it is
considered to be the most fragile one. Furthermore,
we expect a continuous contribution and feedback of
the client in order to keep our work as informed has
possible at all time.
Business Processes Model
Figure 5: Relations between business processes and
information entities on the second iteration.
After doing a survey of the enterprise business
processes and information entities we started
describing the “AS-IS” state. On the process of
gathering all the processes, we tried to make
correspondence between them and the macro-
processes defined on the first iteration, as a way to
understand how far the reality of the organization is
from the reference model. We must keep in mind
that although the reference model constitutes an
example of good structure for the business, it is not
the only possibility.
Current Systems & Technology
Figure 6: Relations between business processes and
current systems on the second iteration.
After performing some interviews and research we
were able to identify the main systems supporting
the business. On this iteration we tried to include
only the critical systems and the ones that are
considered by the stakeholders as being the most
important ones.
Data Architecture
Figure 7: Relations between information entities on the
second iteration.
After analyzing the information entities identified
before, and reaching a clear understanding of their
characteristics, purposes and use cases, we can
achieve a new and more detailed data architecture
ExtremeEnterpriseArchitecturePlanning(XEAP)-ExtrapolatingAgileCharacteristicstotheDevelopmentofEnterprise
Architectures
381
that shows a suitable structure capable of fulfilling
the business demands in an effective way, free of
incompatibilities between entities.
Applications Architecture
Figure 8: Second iteration CRUD matrix.
On this second iteration with a new CRUD matrix,
we were able to identify 5 main systems that can
support in an efficient way the business processes
and information entities described on the previous
steps.
Technology Architecture
We don’t have, yet, enough information to present
this step.
Third iteration
We don’t have yet enough information to present the
third and last iteration.
5.2 Analysing Preliminary Results
The methodology used by GFI is based on the
standard flat methodologies, such as EAP where
they describe the entire “AS-IS” state of the client
with a big level of detail in first place, and then
move to the final definition of the “TO-BE” state.
With this approach is easy to understand that the
time to value of the project is as much as the total
duration of that same project (3 months). On the
case of our proposal we were able to deliver results
on the first meeting with the client through the
presentation of the work developed during the first
iteration described before on this document, as a
way to start the discussion and get some valuable
feedback from the client. Soon on the project, we
will be able to present an accurate architecture to the
client with reasonable level of detail, although not
final, with the description of the work developed
during the second iteration. At the end of the project,
both we and the consulting company will be able to
present the final architecture with the same level of
detail concerning the business processes and
information entities of the organization, varying only
the time that each one will take to achieve it.
6 CONCLUSION
On this work we tried to do a concise overall
description of the artefact that we have been
developing. Our work consists on an iterative
process capable of delivering faster results when
compared with the traditional and most used
methodologies. XEAP minimizes the negative
impact that uncertain requests tend to have on the
standard methodologies, by using iterations that can
access previous feedback, and use it as a way to
drive the project into the right path with constant
adjustments. The combination of those iterations and
the reference models, brings the capacity of
delivering results to the client a really early stage,
that despite not being final results, are preponderant
on the feedback necessary to correctly conduct the
project.
The fact that we are applying our proposal to a
real world case study currently happening didn’t
allow us to present the entire final results, and
therefore the final evaluation process. Although
being a limitation to this document, this can also be
seen as good way to show XEAP effectiveness on
the delivery of fast results, once the client is already
in possession of valuable information which will
certainly be used to guide them on their
transformation process.
As we said before, we were not able to get all the
final results from the XEAP process. This means
that although the faster results achieved at the half-
point of the process, as future work, it will be
necessary to compare both the quality and the
delivery time of the final results, once that will be
the most important test to the effectiveness of the
methodology.
ACKNOWLEDGEMENTS
We would like to thank GFI Portugal for their
cooperation on the demonstration process of our
artefact and the scholarship provided to help on the
development of our work.
ICEIS2014-16thInternationalConferenceonEnterpriseInformationSystems
382
REFERENCES
APQC (American Productivity & Quality Center), 2012.
Process Classification Framework.
Beck, Kent, 1999. Extreme Programming Explained.
Becker, J., Delfmann, P., Knackstedt, R., 2007. Adaptive
Reference Modeling: Integrating Configurative and
Generic Adaptation Techniques for Information
Models.
Brooks, JoAnn M., Bread, Jon W., & Carrol, John S.
2008. The Changing Nature of Systems Engineering
and Government Enterprises: Report from a Case
Study Research Effort.
Land, Martin O., Proper, E., Waage, M., Cloo, J. &
Steghuis, C. 2009. Enterprise Architecture - Creating
Value by Informed Governance.
Ramesh, B., Jarke, M. 1999. Towards Reference Models
For Requirements Traceability.
Schekkerman, Jaap, 2011. Institute for Enterprise
Architecture Development - Enterprise Architecture
Tool Selection Guide.
Schwaber, Ken, 1995. SCRUM Development Process In:
Object-Oriented Programming, Systems, Languages &
Applications.
Spewak, Steven H. & Hill, Steven C. 1992. Enterprise
Architecture Planning: developing a blueprint for data,
applications and technology.
Spewak, Steven H. & Tiemann, Michael, 2006. Updating
the Enterprise Architecture Planning model in Journal
of Enterprise Architecture.
Sommerville, Ian, 2010: Software Engineering – 9
th
edition.
The MITRE Corporation, 2004. EABOK - A Project of
The MITRE Corporation.
The Open Group, 2009. Togaf Version 9 - The Open
Group Architecture Framework (TOGAF).
Townsend, Jaap, Hedges, M. & Hobson, P. 2008. Doing
Enterprise Architecture: Enabling the agile institution.
ExtremeEnterpriseArchitecturePlanning(XEAP)-ExtrapolatingAgileCharacteristicstotheDevelopmentofEnterprise
Architectures
383
