<<If you've been paying attention, one of the things that the movement
to the sort of agile IT that service-oriented architecture (SOA)
enables is a new set of roles and responsibilities in the
organization. We often blame today's IT departments and their
technology purchases for being responsible for the integration rat
nests that are the cause of today's inflexibility, and we frequently
chastise the business folks for making expedient, short-sighted
decisions that only make the problem worse. So, is there a way out of
this puzzle? Is there anyone in the organization that can hope to get
the vision of service orientation right or is this all a hopeless
struggle?

Fortunately, there is hope and it comes in the form of enterprise
architecture. As we've frequently discussed, the most critical part of
making SOA work is doing architecture well. So, if there's a need for
architecture, then it figures that there's a need for architects.
After all, if we need an architect for something as relatively simple
as a house or office building, then it makes sense we need someone in
the corresponding role for designing systems as complex as today's IT
environments.

Now, this is where things get a bit dicey. Just like every other term
we use is hopelessly overloaded with multiple meanings that are often
contradictory, so too does the term architect invoke continuous
teeth-gnashing. After all, while building architecture can be quite
solidly constricted to the domain of physical habitats, the
notoriously amorphous space of IT has us wondering about similarly
defining the scope of architecture. Are we talking about network
architecture, information architecture, systems architecture, business
architecture, enterprise architecture, some sum of all the above, or
some new thing that addresses a new need?

This is what causes the blood pressure to rise in those in the
community that already perceive themselves as architects of one
fashion or another. If you've been around long enough in IT, you've
probably built your own base of knowledge, best practices,
methodologies and technology concepts that you can wrap into a bow and
call architecture. And if it's good enough for you, then darned it,
it's good enough for everyone. Right? WRONG.

What businesses want are individuals connected inherently with the
business of the organization and not today's technologies that
approximate (at best) how the company operates. These sorts of
individuals we have been referring to as enterprise architects, but
perhaps there is a better term for these folks. For now, let's just
assume that the above term defines a specific set of capabilities in
individuals.

So, what do we expect from these individuals? First, these individuals
aren't just developers with enough experience to say what works and
what doesn't. They have a specific set of talents that simply cannot
be organically grown from an arbitrary individual in the IT
organization. Specifically, this breed of enterprise architect, the
kind that can make the business stand up and recognize how to best go
about something, rather than just a part of the IT department, is a
rarity in the organization.

Good enterprise architects have six core talents that they master in
order to give the business organization the strategic capabilities of
leveraging IT in the face of continuous change. They must be great
communicators – no ifs ands or buts about this one, no communication
means no ability to connect the parts of the organization together.
Good architects realize that nothing ever stays the same. As such,
architects are responsible for not just meeting today's requirements
using today's technologies, but managing change as well. It thus falls
upon the shoulders of the enterprise architect be the champion of
thrift and extend the value of existing IT investments. Such
architects must be able to find ways to reduce the need to invest in
unnecessary technology and allow companies to build systems that can
evolve with changing needs. Good architects must be more than great
communicators, simplifiers and economic magicians—they must also be
able to make realistic, step-wise improvements to the business use of
IT. Finally, good architects must understand best practices, since
they are the masters that make it happen.

Yet, while there's a glut of developers who can piece things together
if you can give them the proper context, there's a dramatic shortage
of skilled enterprise architects with the above talents to make SOA,
or any long-term initiative, work in the face of continuous change. In
part, there's not enough knowledge or skills in the industry to mature
wanna-be architects into full blown architect professionals. ZapThink,
along with other groups, are seeking to improve this lot by
introducing SOA-specific and EA-specific credentialing and skills
uplifting such as the Licensed ZapThink Architect program and Open
Groups's AOGEA efforts.

But more than that, there are indeed a growing base of enterprise
architects with the above credentials who are not only available, but
willing to help companies make the transition from need-it-yesterday
and need-it-cheap IT project-by-project decision making to
architectural strategic planning that considers IT as a set of agile
resources to be utilized by the business. Through ZapThink's Architect
Resource Center as well as other efforts, we are trying to help raise
the visibility of these architects with specific skills in human
interaction. Already, dozens of such architects are now in the
database, with more added daily.

It may sound like a daunting task to bring together all the necessary
people required to make SOA a success, but even the largest companies
probably have no more than a few dozen enterprise architects with the
necessary scope of responsibility to be important additions to your
SOA efforts. Your key is to find these cherished and skilled
individuals so you too can be on the road to effective enterprise SOA.>>

You can read this at:

<http://searchwebservices.techtarget.com/tip/0,289483,sid26_gci1242414,00.html?track=NL-451&ad=578716&asrc=EM_NLC_984837&uid=5532089>

Gervas

Reply via email to