I have worked in the IT field for over 3 decades now, and
I’ve seen a lot of effort expended in design, architecture and infrastructure areas
to build out some incredible and fantastic platforms and underlying
systems. However, I’ve never seen a 100%
utilization of that effort. In general a
large part of the work is never used or, even worse, becomes a blocker to
future agility. Why do we do that? Why do major components of these
architectural designs, many built by some of the most intelligent people I
know, go unused? From my experience, it
is always due to our tendency to separate architecture usage from business
feature usage. Architecture alone does
not add to our bottom line or overall success.
It is only when that architecture or design enables us to solve customer
problems that business value is achieved.
Architecture, design, UX, and any other similar effort
should only be expended in the pursuit of supporting business value. Yes, Architects, Designers, etc, I do mean
that without the business value you support you have no reason to do the
work. And, even more importantly, unless
you are building architecture to directly support currently needed business
value, you have no way of validating if you have designed the right
architecture! Only after validating your
design by seeing it enable business value do you know if you have built a valid
architecture.
From an Agile perspective, this makes sense. Agile Principle # 10, the art of maximizing
the amount of work not done, stresses that the simplest solution is often the
best solution. From a Lean perspective
we are pushing to eliminate waste in the system; unused architecture is a huge
source of waste (as well as quality issues).
Add in the Lean Startup perspective, which brings to the table that
sense of experimentation to gain knowledge quickly, and we gain the perspective
that true validation only comes from the customer. Then apply all 9 SAFe® principles (yes,
Intrinsic Motivation counts) and you start to see the picture that we should
only consider architectural effort well spent and validated once we see it
supporting business value and solving customer problems.
“But, wait!” you say, “if we delay creating architecture/infrastructure/design,
we end up with a fragile mess!” True
enough, we definitely need to have intentional architecture so that we have a
consistent and supportable direction with our designs. We absolutely need to be looking ahead for
the architecture, designs, patterns, infrastructure, and all the other needed
components to support business value.
Enter the SAFe®
Architectural Runway. This Runway
combines Intentional Architecture and Emergent Design to ensure that we are
building the right amount of architecture up front, but ensuring that all of
our efforts can be quickly validated by supporting actual business value.
Intentional Architecture
Where are we going with this solution? What framework, capability, etc will be
needed to support future business value?
What do we need in place to avoid future performance issues? Are we headed in a direction that supports
future security concerns? Those are all
things that need to be discussed and planned for. However, each discussion we have should be
accompanied by “what business value is upcoming that can validate this is the
right direction?”
Emergent Design
Emergent Design
is a core component of validating architecture incrementally. The ability to create a ‘walking skeleton’ of
the intent and then allowing the details of the design to emerge from the teams
each increment allows us to validate the value of each architectural component
as we progress. The key is to ensure
that we are establishing our measurements and leading indicators of the
viability of the architecture and design we are pursuing. Having a direction is the first step, but
then we need the teams to build to that intention, and then stack business
value on top to validate the intention.
For example, let’s assume you are trying to move your
application base to the cloud. Your
assumption is that moving your entire infrastructure to the cloud will result
in cost savings and the ability to scale capacity much more quickly. However, you have a massive amount of
applications to manage, that all seem to be inter-connected, and you cannot
interrupt operations. In addition, most
of your footprint is legacy apps that are client-server or mainframe based
design. A traditional mindset would
state that you need to design a cloud capability to support all of these apps
and their connectivity (which means migrating a number of mainframe apps) which
will require a massive application and workflow design. And you are correct, you do need a plan, but
as von Moltke stated “No Battle Plan Survives Contact With the Enemy”. Applying Intentional Architecture along with
Emergent Design is the way to survive this massive effort.
Instead of pursuing a big bang approach to this effort,
pursue an incremental, learning based approach to the architecture and
design. What early indicators would help
prove we have the right concept of how to move to the cloud? What early value can we pursue that will not
only help us determine the right direction, but also confirm the perceived value? The first step is to have a firm plan that is
easily changed. Create a clear vision of
where you want to go, and your approach to getting there, but create the plan with
a high level of abstraction. Avoid the
locked in design that can result from going too deep too quickly. For each component of the design ask yourself
“How does this support the business outcome we are looking for?”
Next, determine the architectural/design areas that are the
most mission critical or present the most risk.
It is important to isolate these areas to be targeted for early
learning. Look for areas that will not
only gain knowledge on the architectural direction, but also support the most
business value, both of which will provide faster feedback on future
direction. Avoid the ‘sacred cows’, the
areas that you want to put in, but
don’t really need. Add in the understanding of how you will
measure this progress, looking for leading indicators that will help to provide
faster pivot or pursue moments. For
example, if part of your reasoning for moving to the cloud is cost savings,
determine how you can measure cost savings with each increment. Sometimes you have to extrapolate or use
non-monetary indicators early on, but get as quickly as you can to real savings
measurements.
Now, build the bare minimum architecture you can to gain the
knowledge you need, e.g. to move your metric needle forward. If your assumption is message based
connectivity in the cloud, but you are using file based communication in many
areas, can you first get these apps to talk via a simple message queue or
service bus? Do you really need to move
to the cloud before you have built the first step of communication? As you build these incremental steps you
start to play leapfrog: a little architecture, a little business, rinse and
repeat, all while keeping an eye on the end target.
Both Emergent Design and Intentional Architecture require
Validation to be successful. The
Architectural Runway is there (in part) to ensure that we are recognizing that
need for validation. The next time you
are thinking of this cool new platform concept, wanting to implement the latest
My/No/Yours SQL, remember to think “what business value needs this? What business value can we build on this
capability to validate we are going the right direction with our intent? How can we quickly measure the success of the
design?” Then, build that business value
on the early iterations of that architectural work, and look for customer
validation for course validation or correction.
No comments:
Post a Comment