1. Beyond Agile Projects: Agile IT
Executives need the business to be adaptable to the continu-
ous business changes. This has implications on the organiza-
tion, business structure and processes, offering, and other
business dimensions. Often, IT legacy is what prevents the
business from moving at the speed it needs.
IT in many organizations has evolved over decades. During
this time it has built in structure, integration points, depend-
encies, and habits that are difficult to change. And even if the
organization is new, as in a start-up, you may be building to-
day what will prevent you from being agile tomorrow.
On the other hand, we are nearing 20 years of project-level
“agile” best practices. We have now tried out these practices
on a variety of projects, teams, and organizations. We know
what works and in which contexts.
The Agile Architecture Company™
This paper illustrates the state of the art of agility in the en-
terprise, the relationship between agility at the IT enterprise proach, COSM adopted terms and concepts from other agile
level and project-level practices, and what is needed to suc- methodologies such as Scrum and XP.
ceed.
Project Agility today
Brief history of project agility
Today, the practices of agility at the project level have largely
In the 80’s, many organizations were experimenting with new matured, both in its methodology elements and in its other
processes, best practices, organizational concepts, and archi- dimensions.
tectural styles to make projects more agile. This included
iterative OO methodologies, spiral, RAD, and others. At the methodology level, there is a convergence of many
best practices. For example, for small to medium projects,
In the mid-90’s, a number of efforts evolved similar practices. we all tend to use sprints, stories, backlogs, TDD, scrums,
In 1992, Peter Herzum defined and applied the concepts that and frequent releases. For larger projects, we integrate fea-
became known as COSM Project. COSM brought together a tures and stories (and in some situations, even use cases),
number of architecture-centric agile best practices such as iterations and sprints, user-centered design, continuous as-
component-based development, iterative development, fea- sembly, and others. Many organizations also adopt architec-
ture-driven development, continuous assembly, test early and ture-centric agile concepts, such as component-based and
test often, and others. He and Oliver Sims formalized, with a service-oriented development.
focus on architecture, these best practices in papers pre-
sented at OOPSLA and ultimately in the best-selling Today, it is also known when to apply what. For example,
“Business Component Factory” book. In 1993, Jeff Sutherland COSM encourages projects to perform a COSM Project Pro-
experimented with the first Scrum concepts, which Ken file early in the project, so to select practices appropriate to
Schwaber formalized in a paper at OOPSLA 1995. Scrum was the project size, complexity, objectives, organizational matur-
described as a framework with three roles, three ceremo- ity, and other elements.
nies, and three artifacts designed to deliver working software
in sprints. In 1999, Kent Beck and others introduced eXtreme Most importantly, there is a significant body of experience
Programming (XP) to the public as a set of lightweight devel- today on the non-methodology key areas to be addressed for
opment practices, and a discipline of software agility: architecture, factory setup, project support, organiza-
development that follows a set of rules designed to simplify tion, and the project context.
and expedite software development.
Architecture: The ability of a project, and ultimately of an
Over time, methodologies have cross-pollinated; aligning ter- application, to withstand rapid changes and evolutions of re-
minology or integrating the best elements from other prac- quirements and capability depends on the architecture being
tices. For example, while keeping its architecture-centric ap- “adaptive”.

2. Agile architecture practices, both in the sense of what it takes
to make the architecture agile, and in the sense of how to
integrate an agile definition of architecture in the overall agile Application Agility
lifecycle, are now well-established.
At some point, every project ends. If successful, it typically
Architecture-centric agility refers to the belief that adaptive delivers an application, or a new version of an application.
architectures, and ultimately any agility beyond an individual Depending on how the project was defined, the application
project, can only be obtained by also addressing architecture is delivered either to another IT team (for example, for pre-
in its various viewpoints. Capability to rapidly adapt to new production testing, integration, migration) or directly into
requirements is not only a process or technology challenge: production. Soon thereafter, the project team is often dis-
there are application architectures that more or less naturally banded. At this point, Application Agility, i.e. the ability to
support changes. For medium-large projects, these architec- adapt the applications to new requirements rapidly and cost
tures are typically component-based and service-oriented. -effectively becomes a primary consideration.
Today, experienced organizations can pre-define many techni- The deliverables and best practices applied at the project-
cal, structural, and functional elements of an adaptive architec- level, or even the definition of what project agility means,
ture, and by so doing can significantly reduce time-to-market, can be significantly impacted by the inclusion or exclusion of
enhance quality, improve productivity, and reduce waste. Application Agility objectives in the project. For example:
whether the application properly supports integration with
Software Factory Setup. Agility relies and benefits from other applications and migration from a previous application
automation, especially on significant projects. Many elements database may affect the architecture and the level of docu-
of the code can be generated. Continuous assembly requires mentation required by the project.
scripts to make it efficient. Test code can also be largely gen-
erated. Relationship between requirements and their tracing Agile best practices today must cover not only the project
can benefit from tools, and so can planning and reporting. This lifecycle (from requirements to release to acceptance) but
is why agility and software factories go hand in hand. also the application lifecycle (the “software supply chain”),
including migration, integration with other applications, de-
Statistically speaking, in medium-large projects, the “setup” ployment, maintenance, and evolution.
part of the first version of an application release can cost 70%
of the overall budget. This means that the factory setup itself Application Portfolio Agility
requires optimization and agility. Statistics also say that a
proper factory setup can reduce development costs (including It is not surprising that IT can not always keep up with the
design, code, unit tests) by 20-25%, and maintenance costs of new demands of the business after years or decades of inte-
30-40%. It can also reduce cost of learning new technologies gration projects between redundant applications, of rapid-
by 50-60%. but-often-unmaintenable evolution of applications, and of
“don't-touch-it-if-it-works” applications that now have obso-
Project Support. Support for collaboration has dramatically lete technologies.
improved in the last few years. This is particularly important
since many development teams do NOT have the luxury of Organizations today are often concerned not about chang-
working co-located in a “war room”. Integrated tools for ing one single application, but rather about changes and ini-
knowledge databases, wikis, efficient story/issue/change man- tiatives that affect an integrated set of applications. This re-
agement systems can support communication, collaboration, quires addressing agility at the application portfolio level.
and ultimately success. Program managers, IT managers and executives, and enter-
prise architects are looking for ways to simplify their portfo-
Organization. There is a team behind every project success. lio, rationalize their cross-application enterprise architec-
And teams are complex systems composed of complex indi- ture, and govern new projects to assure that they align with
viduals. The context-specific organizational patterns that can the enterprise business and IT objectives.
enhance chances of team success, and the experience on how
to mentor/support them to success, is available today. There are fewer and fewer applications that are truly
“autonomous”, and very few projects that are allowed to
Project Context. Projects interact with other projects. And define “their own practices”, and “their own architecture”.
must relate to pre-existing enterprise contexts: pre-existing Enterprises are looking for ways to adopt project-level agile
business processes, pre-existing applications or services with practices while driving toward agile IT.
which to interoperate, pre-defined technologies, and more.
The ability to integrate these contexts is a key element of “Agile” meet Enterprise architecture
modern agile projects.
Over the last 20 years, many companies have launched en-

3. terprise architecture (EA) efforts, for a variety of reasons that the company’s business objectives.
often include making the whole enterprise (not only individual
These characteristics are the success criteria that allow
projects or IT) more agile to change. companies to manage IT as an agile business, to align busi-
ness and IT, and use IT for their innovation and competitive
For many project “agilists”, dealing with an EA team or with an
advantage.
EA reference architecture is the exact opposite of what they
would consider “agile”: they believe they have to deal with
constraints, deliverables, and complexities that slow down COSM: an Approach for Agile IT
their ability to proceed rapidly to the desired solution. On the
other hand, this is enterprise reality today. The agility dimensions described in this paper are well-
known. At Herzum, over the past 10 years, we have experi-
Luckily, it is possible to align agile IT, enterprise architecture mented both with traditional agile methodologies such as
efforts, and project agility. It requires long-term planning, co- Scrum and XP, and with scalable architecture-centric ap-
ordination, and enterprise-level architectural patterns. It re- proaches. The result of all these activities has lead us to
quires experience in organizational transformations, and coor- continuously evolve and optimize our project-level, archi-
dinating organizational phases top-down with the project-level tecture-centric agile approach: COSM Project.
iterations and sprints.
At the same time, we have worked with medium and large
It is of course a question of balance. But often, enterprise-level enterprises to help them optimize IT, their application port-
agility best practices trump project-level practices. folio, and their enterprise architecture. We have also helped
them align IT to the business, use IT for competitive advan-
Agile IT tage, and transform their organization. All of this has al-
lowed us to strengthen, optimize, and evolve the enterprise
Ultimately, the continuous journey toward an increasingly Ag- best practices that are today synthesized in COSM Enter-
ile IT requires a number of dimensions to come together. The prise, our agile IT approach.
good news is that many of the best practices to support this
have matured. With some simplification, an Agile IT today has COSM today covers projects, enterprises, and the alignment
several key characteristics. of projects to the enterprise context. It has integrated best
practices to solve specific project problems, but also to de-
First of all, the enterprise has rationalized (or is in the process fine IT strategy and enterprise architectures that are permit-
of rationalizing) their application portfolio. This often requires ting enterprises and IT teams to solve the various challenges
a 3-5 year-long transformation program, supported by an en- of continuous change, continuous cost reduction, and con-
terprise architecture team and a good Reference Architecture, tinuous business/IT alignment.
that eliminates or reduces the application redundancies, the
technology redundancies, and the integration approaches. COSM goes beyond the agile development lifecycle to cover
the agile software-supply chain, the agile application portfo-
Application portfolios often consists of coordinated sets of lio, the agile IT, and ultimately support the Agile Enterprise.
purchased and built applications. New applications are being
built, deployed, and operated by outsourced organizations. It
is becoming crucial to IT agility to have clear rules for these
organizations to cooperate toward common goals.
The enterprise-level management and governance process for
strategy, on-going IT management, operations, project man-
agement, and application management have been optimized.
The project level agile practices feed into the enterprise proc-
esses and are aligned with them.
The ability of financially managing IT, including ability to prop-
erly calculate costs, value, benefits of IT assets, projects, appli-
cations, and ability to monitor progress of individual projects
is, also due to the current economic crisis, a prominent char-
acteristic.
Paramount is a culture that on the one hand fosters innova-
tion, cooperation, and transparency, and on the other hand
provides clear alignment of individuals, teams, and projects to

4. Herzum “The Agile Architecture Company TM”
Consulting Practices
Companies around the world leverage our experience to kick-start and deliver their projects on-time, and optimize their IT
assets and organization. Our consulting practices include:
• IT Strategy and Enterprise Architecture
IT Strategy and Management, Business Modeling and Enterprise Architecture, Portfolio Management, COSM Services,
Assessment and Roadmaps, and Software Product Development Strategy.
• Project Consulting and Software Architectures
Program and Project Management, Software Architecture, Agile Software Development, Component-Based Development,
Software Factories, Development Processes, IT Integration, and Service Oriented Architectures.
• Software Development and Cosourcing
Cost-effective, quality development of large and small projects, with particular skills in mission critical applications and
e-commerce solutions. Costs and time-to-market can be reduced using our pre-defined software factories, processes,
and components.
• Herzum University
Our acclaimed and architecture centric courses and workshops are guaranteed to satisfy the needs of all professionals in
your organization: Executive Briefings, Enterprise Courses, Architecture, Methodology, Technology, and customized
courses and curriculums for your specific needs.
Company
With offices in the United States and Europe, Herzum is an international consulting group with a successful track-record of
helping enterprises innovate and align business and IT, while concurrently reducing IT and development costs. A leading
authority in IT strategy, enterprise architecture, and agile software development/integration, Herzum is particularly known
for its cosourcing centers and its COSM approach. Our company specializes in architectural and organizational migration to
new technologies, strategic e-business solutions, and software reuse. With a network of strategic alliances with service and
product companies, Herzum handles projects and organizations from start-up phase to Fortune 100 level.
United States Italy
Herzum North America, Inc. Herzum srl.
175 N. Franklin St. Via Boccaccio 18
Suite 301 20123 Milan Italy
Chicago, IL 60606 USA Tel: +39.02.4125347
Tel: +1.312.602.1001 Fax: +39.02.48370338
Fax: +1.312.602.1002
United Kingdom Turkey
Herzum Limited Herzum
1 Tranmere Court Solveka Yazilim Limited Şirketi
Guiseley, Cyberplaza A-Blok KAT: No:A703
Leeds LS20 8NA 06800 Bilkent
England Ankara,Turkey
Copyright © 2009 Herzum, Inc. All Rights Reserved www.herzum.com