 |
Many people mistakenly assume
that enterprise-level activities, such as
enterprise architecture or
strategic reuse, need to be performed in a
traditional and even bureaucratic manner.
As I've shown with the
Enterprise Unified Process (EUP), nothing
could be further from the truth. The way
that enterprise professionals organize
themselves and work with their customers, which
include both software development teams as well
as business stakeholders, can be agile. My
experience is that there are several strategies which enterprise
professionals, such as enterprise architects or
enterprise data administrators, can adopt to become
more agile. Agile strategies for
enterprise professionals include: |
|
- Collaborate, don’t control. Agilists
collaborate with others to achieve their goals.
They inherently know that
communication is critical
to their success and they do everything possible to
break down any barriers to communication which may
exist. They realize that the best use of their time
is to actively work with others, that trying to
control others from afar via defined procedures or
decrees is a futile effort at best.
- Focus on delivering working software on a
regular basis. Software development teams are
an important customer of enterprise groups, and the
primary goal of software development teams should be
to develop software. If you are able to help them
to this then you will be perceived as a valuable
resource to work with, otherwise you will be
perceived as an impediment to success and they will
find ways to go around you. Yes, project teams are
often narrowly focused on their own goals and are
usually under tight time constraints, but that
doesn’t mean you can’t help them to take enterprise
concerns into account without impeding their
progress. But it’s up to you to find a way to be an
effective member of that team.
- Focus on working closely with business
stakeholders.
Active stakeholder participation is a critical
success factor for any IT endeavor, be it a single
development project, a program of projects, or some
sort of enterprise modeling effort. It is easy to
forget this, or to convince yourself that you know
best and therefore can take on the role of
stakeholder, or to give up when your stakeholders
claim that they’re too busy to be actively
involved. The risk of building something which
doesn’t meet the true needs of the business far
outweigh the cost of obtaining active stakeholder
participation.
- Embrace change, don’t fight it. Change –
truly new requirements, an improved understanding of
existing requirements, or new/improved technologies
– is a cold, hard reality that we all face.
Agilists accept that change happens and find ways to
become efficient at responding to change. This can
be very difficult at first, particularly because it
involves the adoption of a new mindset and new ways
of working. In the end, isn’t it better to follow
an agile approach which reflects your environment
rather than a traditional approach which doesn’t,
even though you may not yet be comfortable or
familiar with this new approach?
- Be customer oriented. A primary goal of
enterprise architects should be to support and
hopefully guide both software development teams and
even the business. To do this effectively
enterprise architects must be customer-oriented and
that implies that they must find ways to work in a
manner which reflects their customer base. It is
important to recognize that a business modeling team
will very likely work in a different manner than a
team of seven developers taking an
Extreme
Programming (XP) approach who in turn will take a
different approach than a forty-person
Feature
Driven Development (FDD) project team. Therefore,
customer-oriented enterprise architects will find
ways to work with each of these groups in a manner
which reflects their unique situation. The
implication is that an enterprise group must be
flexible and prepared to work in ways which may not
be ideal for them.
- Share your skills. An important agile
philosophy from the
EUP is that enterprise professionals should be
responsible for sharing their skills with others.
Figure 1 depicts how creation
and support of development guidance, training of
people in enterprise architectural concepts and the
architecture itself, and mentoring people in those
topics is an important aspect of the overall
enterprise architecture discipline. Creating
development standards and enterprise architectural
models is important, but it's unlikely that they'll
be followed without direct support from the people
responsible for them.
Figure 1. Enterprise architects should
support development teams.
- Adopt a governance approach based on
collaboration and enablement. Traditional
governance approaches often take a
command-and-control approach, which is exactly
opposite of the way you should work with
intellectual workers. A better strategy is to
adopt a
lean development governance approach strategy
based on close collaboration and enablement which
reflects the way that intellectual workers behave in
practice.
- Focus on value. Agilists are constantly
asking the question what is the value of doing
something, and if there isn’t value then they
rethink their approach.
- Constantly ask if there’s a better way. Agilists
will also ask themselves if there is a better way to
achieve the same sorts of goals. For example, the
fundamental goal of holding a
review is to ensure that several people have
examined an artifact to ensure that it meets the
needs for which it was created and that it was of
sufficient quality. There are more effective ways
to achieve the same goal: the adoption of practices
such as collective ownership,
pair
programming, and
modeling with others ensures that several people
will work with the code or models respectively. The
point is that you need to question your assumptions,
many traditionalists will assume that you need to do
reviews because you can’t trust the work of
development teams whereas the real problem is that
people on the teams worked in relative seclusion
from one another and therefore were in a position to
create poor quality work that wouldn’t be detected
without a review. A side effect these practices is
that reviews are effectively held in parallel.
Context counts – reviews are best practices on
traditional projects that don’t promote
collaborative work, but they often prove to be
ineffective practices on agile projects which take a
highly collaborative approach.
- Optimize the whole, not the parts.
Many enterprise-level efforts fail when they attempt
to sub-optimize one or more disciplines, such as
operational database administration or
human resource management, instead of optimizing
the
whole IT lifecycle. The end result is that
although your data management processes may be
effective on their own, when taken into the overall
context of the rest of IT they're not only out of
synch with everything else but they're actually
hampering your organization's ability to be
effective. Optimizing the whole is one of the
lean principles.
|
 |
I hope that you have noticed that my first four
strategies are basically rewordings of the
four values
of the
Agile
Alliance (AA). The AA has some pretty good
advice to share with you, I highly suggest visiting this
site on a regular basis.
 |
|
The Object Primer 3rd Edition: Agile Model Driven
Development with UML 2 is an
important reference book for agile modelers,
describing how to develop 35
types of agile
models including all 13
UML 2 diagrams.
Furthermore, this book describes the techniques
of the
Full Lifecycle Object Oriented Testing
(FLOOT) methodology to give you the fundamental
testing skills which you require to succeed at
agile software development. The book also
shows how to move from your agile models to
source code (Java examples are provided) as well
as how to succeed at implementation techniques
such as
refactoring and
test-driven development
(TDD). The Object Primer also includes a
chapter overviewing the critical database
development techniques (database refactoring,
object/relational mapping,
legacy analysis, and
database access coding) from my award-winning
Agile Database Techniques
book. |
|
|
|
Agile Modeling: Effective Practices for Extreme
Programming and the Unified Process is the seminal
book describing how agile software developers approach
modeling and
documentation. It describes principles and
practices which you can tailor into your existing
software process, such as
XP, the
Rational Unified Process (RUP), or the
Agile Unified Process (AUP), to streamline your
modeling and documentation efforts. Modeling and
documentation are important aspects of any software
project, including agile projects, and this book
describes in detail how to
elicit requirements,
architect, and then
design your system in an agile manner. |
 |
|
The Elements of UML 2.0 Style describes a collection
of standards, conventions, and
guidelines
for creating effective
UML diagrams. They are based on sound, proven
software engineering principles that lead to diagrams
that are easier to understand and work with. These
conventions exist as a collection of simple, concise
guidelines that if applied consistently, represent an
important first step in increasing your productivity as
a modeler. This book is oriented towards
intermediate to advanced UML modelers, although there
are numerous examples throughout the book it would not
be a good way to learn the UML (instead, consider
The Object Primer). The book is a brief 188
pages long and is conveniently pocket-sized so it's easy
to carry around. |
We actively work with clients around the world to
improve their information technology (IT) practices,
typically in the role of mentor/coach, team lead, or trainer. A full
description of what we do, and how to contact us, can be
found at Scott W.
Ambler + Associates.
 
|
