Tempus Fugit.
Double-O-7, tortured and bleeding, whispered
in the ears of Dr. Madeline Swann, "Tempus Fugit." She then threw the time bomb devised by Q,
towards the sinister Blofeld, for an explosive diversion and escape. Indeed, time flies (in spite of the run-on tendencies). And here we are, somewhere at the midpoint of the term, where we have supposedly reinforced what we
know, as we continue our learning journey of Enterprise Architecture. As you can see from the diagram below, we're
also midway towards the end of the navigational roadmap. A well-known effective
devise, it's good to come up for air, and check where we've been, get our
bearings straight, before we continue to dive again and learn some more.
A Good Day for Drawing.
Using Gartner's Navigational guide for
EA (deliverables) above, I went ahead and worked on an exploded view of the
future state area. Hopefully the diagram below serves to highlight what I think
are the key playing components, when we are at that particular stage, focused on communicating future state. Things became more clear to me as I
was drawing, and my purpose is to share and validate this clarity with
readers. At any rate, it was a good
breakfast -- a typical weekend delight from my wife, and hopefully you'll agree
that it served me well.
Where's the Customer?
Please make no mistake -- this picture
embodies a customer focused philosophy.
Ironically, the customer labels are missing in the diagram. But this is
by design, because everything in this model segment revolves around customer
focus i.e. the spirit of the customer is everywhere. Internal customers, as
organizational units work to serve each other, define the efficiencies and
effectiveness of the business. Obviously, the actual business customer to which
the organization evolves its business, is the reason for being -- our raison d'être.
The vision of this business customer is critical to keeping the business
organization alive in the ecosystem, such as the marketplace, or society in
general.
Revisiting Business Context
The model also comes back to why we need
a solid understanding of the business context for the organization, to which we
develop and serve the enterprise architecture.
The Business Context gives us a clear view of the environment to which
we will implement our initiatives; i.e. the operating model that the business
has chosen, the organizational culture and capabilities in place, and the
trends -- technology among others, to which the business needs to react and/or
adapt. Moreover, the Business Context gives us a strong foothold with which we
anchor our understanding of mission, goals, and strategies; to which, in turn, we work
our architectures in pursuit of constant alignment. Note that I have placed the
gears near the alignment box to indicate where I feel the bulk of the work of EA
is done - as mentioned elsewhere I feel this area triggers the messy work of change management.
Stakeholder Viewpoints. Having your Cake and eating it too.
Viewpoints represent each group of
stakeholders' interest on the architectures, i.e. a particular viewpoint takes a focused slice
through any or all of the 4 layers of the future state (Business, Information,
Application, Technology) -- to make sure that IT initiatives are taking care of stakeholders' concerns. As architects, we need
to precisely define these viewpoints, and deeply understand the nuances,
because they serve to keep our communication lines with stakeholders crystal,
to ensure that we evolve our architectures responsive to the key stakeholders'
concerns. Indeed, when architects create these slices with the highest skill,
it is possibly one of the few occasions when we can really say that we can have
as many slices of the "cake", while we keep and wonder at the
beautiful EA cake we made.
An Important Equation: Requirements = Capabilities.
The sets of business capabilities is the
combination of processes, information, people, technology, and other enabling
assets such as facilities and funds.
Business strategies are geared towards developing these capabilities in
order to achieve mission and goals. Capability components are related to each
other, as well as to the Business Context where they will eventually be
applied. Such relationships imply key interfaces, and ultimately require a
definition of responsibilities and ownership.
Achieving a comprehensive understanding of capabilities, therefore, allows the
architect to have a clear picture of the set of business requirements which, in turn,
defines a key driver for the architecture.
Principles. You can run -- but you can't hide.
There are many ways to logically organize and categorize principles. The Gartner conceptual matrix, supplied in the class toolkit, nicely shows a summary form of how principles can cut across and map with other principles, e.g. business vs. information, and business vs. technology.
Happily, these principles, once bought-in, facilitates the justification process for our architectures i.e. makes our lives as architects easier, in line with what was pointed out in class. We should never underestimate the power of these principles, nor should we understate and neglect the promotion of such. As architects, we should repeat these principles in our head, because these sets of principles are the stuff from which we make our magic. Part of our job is to constantly evangelize on the principles at play in the architectures that we provide. At the end of the day, those who will call these architected solutions "home", will be more at peace -- knowing that what they have and use on a daily basis are based on solid rationale, which promotes confidence, that keeps them operationally strong and healthy.
Maturity Growth Towards Mission and Goals.
Notice that the architecture maturity
levels grow towards mission, goals, and strategies. As the enterprise architecture matures, I
should think that the organization will see the tighter alignment of IT
initiatives with business vision and strategies. A happy event for sure, in
which the organization incrementally reaps the benefits of their IT investments -- hopefully creating opportunities to pursue innovation, and in the process, reinforce the competitive posture of the company.
The IT Engagement Model and the Next Steps.
Clearly this way of thinking for future
state communication promotes what Ross talks about as the IT engagement model.
It gives us a picture of relationships, important to understanding the required
governance mechanisms, which in turn, should ensure that business and IT projects will
deliver on objectives. By highlighting mission, requirements, and principles,
it is clear how this segment of the IT engagement model influences decisions
and prioritization of projects; and provides guidance for solutions via enterprise
architecture. For senior management,
such clarity reminds of key results and benefits, facilitates measurement, and
helps maintain an encouraging view of how EA creates value.
So, given these discussions, what
artifacts are key in communicating future state, and how would you present
these artifacts convincingly?
Good luck to all of us on our team submissions
of Case Analysis Part 2.
Cheers, and keep it light.
Complementary blogs:
Other blogs for week 7 nicely complement
this blog. Hasan's Business Context issues, Veena's abstraction levels of
future state models, Susan's nuances of the architectural layers; Jonathan's discussion on principles, with
caveats and the reference to IBM's sample for the financial sector; and Swathika's take of conceptual details from
week 6.
No comments:
Post a Comment