Almost all my life I have been a passionate
software developer. Since I finished the wrong university (studied engineering instead of philosophy) and I had to
re-qualify on fly under a strange combination of lucky stars and unexpected opportunities, till
now, when I can consider myself a seasoned professional with a good nose for
what’s good and bad in any software technology. This last statement takes me to a quote I
read many years back and sounded something like: A
man of culture is someone who forgot everything he ever read. So are the things with a seasoned
software professional: he is a guy who has no more hands-on abilities, forgot how to write good code (the lack of practice being one to blame) but
developed a genuine instinct that tells him immediately what’s going wrong in an
application, or what could make it better.
During my formation years I was ecstatic
about using the keyboard and the monitor, writing lines of code that were processing for minutes and were coming up with something silly in the end: like the result of a calculation by using formulas that nobody needs using in the practical life (Pythagorean triples?), or a
graphic built out from printable characters, or a tinny, shrilly sound made by low quality speakers. Trivial things that at
that historical time (the beginning of the software programming as a separate
discipline) meant the world not only for me, but many other geeks trapped into
a passion that soon was to become addiction. Afterwards, during few years of
professional ferment and innovation craziness, myriads of new software tools and technologies
spread all over the place like an outbreak whose nature and intensity nobody could have predicted. The tiny, shrilly sounds
became symphonic media, the simple graphics made from printable characters
became splendid illustrations hosted by a screen instead of a book cover, and
the calculations which matched up the light speed were soon used to re-calculate the light speed. The transformation was total: the
technology took over everything. The beginner had already stashed in his private workshop of software tools hundreds, if not thousands, of different applications that were meant to cover everything one would ever put his mind with. And if I’m allowed to use a metaphor here, the mountain we started to trek and climb was actually a binary heap, a tall technological riddle, with thousands of different paths possibly leading to the peak. All you had to do was to pick one that suited you.
In the process, the lonely software
programmer who was sweating and swearing in his cubicle with the smell of basement, struggling to build automated solutions for people
who still preferred the wads of paper stashed in their patent-leather
briefcases, found himself surrounded, without even noticing, by a regimen of newly hired co-workers who were now wearing the hats he used to wear before: some of them were doing testing only
(or quality control and assurance), others were writing down the
business needs (or business analysis), others were organizing teams of people
in order to deliver a software solution (or project managers), and last, but
far away from least, there were those guys who needed to take a breath before
starting to write code and think through: For this kind of business requirements,
do we need to build a piece of software, or we can buy? And if we build it, how
complex would that be? Or what if I use this technology instead of that? Wow,
that would save me a few good bucks. Wait, wait, I don’t even need to introduce
the new technology, I can re-use one that we already have in the field. These
are the architects, the people with an organ for conceptual thinking, in
abstract terms, in generalities that can quickly trensform from business prose to technological poetry.
Where did these people come from? Almost
all of them, without exception, came from the developers’ ranks. Those
developers who had become so prolific in their field of activity that the people
started to look at them with trust and respect (some were calling them "geeks" and they meant it!), and asked their advice when in need of a reliable solution. And this is where the things got a bit more complicated. Once a developer,
always a developer, as the saying goes. This little axiom remains valid for thousands of
architects that have been tossed on the land of opportunity by the huge wave of change. They love the coding, they
love the tools, their addiction to hands-on programming is still there, and may never disappear. And what
does this mean? Is this a good or a bad thing? The answer is: depends.
If the architect is part of a small shop
where they actually need a smart developer to do some design work, then by all
means, the guy must know how to code, or at least how to read the code written
by others. And that’s okay: he loves with passion the tools, he loves the code
crafting activity, he enjoys seeing at work the things he created. He will thrive in such an environment and definitely be up to the expectations
If it’s a bigger shop where the money the
shareholders put in the enterprise matter, and their expectations are heavy in terms like accountability, productivity, efficiency then the last person they'd need in their shop would be a tool lover. What they need are architects, of the best breed if possible. True architects.
People with a strong technological background, with an acumen for conceptual thinking, maybe former exceptional
developers who realized that there is more to running a business than
introducing fancy applications developed by the in-house IT departments. People
who love to take care of the forest, instead of counting the trees. People with the touch for
globality, for universality, for integration, which in business world are all alternate terms for enterprise.
It’s not easy to find these people. Some of
them may love the idea of a conceptual, abstract thinking applied to the enterprise boundaries,
but do not have technological acumen. Some others have strong technological
background, but they luck the orientation in the business meandres and the deep understanding
of the processes and their management at the corporate level. The people who
have both are a rare species, but they exist out there. They are called
enterprise architects. And for them they
built TOGAF. Who are they? A group of
people who like to think abstract, to apply structure to the corporate mess, to
look at the same business entity from different perspectives (they call that viewpoints.) They got together through an online call, I assume, and they stick a label to their
group: Open Group. These guys did a terrific job by working together at a product called TOGAF, which is a framework, or a way of thinking, rather than
a set of tools. By the way, TOGAF stands for The Open Group Architecture Framework, and there's nothing fancy about this name, with a Teutonic resonance. Those tools' aficionados who like to call themselves software
architects will reject TOGAF because they will find it dry, uninteresting,
un-awarding. TOGAF is not for them anyway. It’s for the people who wish to
come up with solutions that cross the tight boundaries of the technological citadels, go out there and try to answer to the real needs of the business drivers, and not to their own desire to feel good about what
they do and produce.
Being an enterprise architect is not an
easy thing, because first off you have to listen to sometimes (what do I say, many times) contradicting
feedbacks, face clashing interests, witness the lame shows put up by ignorant, still self-confident individuals, go patiently through a wide spectrum of disciplines, get to know their terms and jargons, and finally building a bridge that can be walked on by everyone who has a stake: this is called negotiate solutions. A negotiated solution will have to be
always in the middle, at that point where all parties cease of being unhappy,
although they are not happy yet. And they may never become happy. This is called compromise, and the people who
achieve this are artists of compromise. From this perspective alone, the
enterprise architects are the artists of compromise, and in their hands the
compromise could become an art. The art of negotiating solutions.
TOGAF is by all means more of a philosophy
and by no means a tool. Although there
are people, very smart people, who had built a tool to support TOGAF. Again: to
support it, not to replace it. The tool is called Sparx EA (stands for Enterprise
Architect) and using it is a pleasure of mind and (professional) soul. If TOGAF is a religion then Sparx EA
is its bible. This tool combines the
best from two worlds: the crystal clear structure of TOGAF (called otherwise an
Architecture Development Method) and the capability of UML 2.0 to capture in a
diagram the design thinking. This tool makes happy both the architects who enjoy
the conceptual thinking and the architects who are still passionate after the
software development tools.
Sparx EA is the right terrain vehicle that takes
us over the slopes and ditches of the rough landscape of the corporate processes
to the flat, serene patch of equilibrium and efficiency called enterprise
architecture.
