It is said that there’s
a tool for every job. But when that job is IT architecture, in all its
permutations, the definition of tool can be a bit fuzzy.
When I set out to get a
sense of what community members consider the most important tool in their
respective architectural toolboxes, I intentionally left the definition of tool
open. I was curious to see how those who responded to my questions would interpret
the term.
One of those respondents
was Farzad Pezeshkpour, head of architecture and engineering for market
and credit risk technology at the Royal Bank of Scotland. His personal choice
for the most important tool is Enterprise Architect from Sparx
Systems.
“In order to do
enterprise architecture well,” Pezeshkpour says, “there must be a
consistent way to represent it, using a number of different views at different
levels of detail, including logical static, logical dynamic, and deployment.
There also must be a consistent naming and referencing mechanism to tie
together all the architecture views. And finally, there must be an enterprise
architecture repository to store and cross-reference these artifacts.
Having
these three core elements in our toolset and processes gives an architectural
management information view that helps govern our estate more efficiently and
intelligently.”
Architecture is deeply
connected to the specific business and technological environment in which an
organization operates. Pezeshkpour works at one company, in one
environment—which is challenging enough. But what happens if your work as an
architect takes you into a variety of different environments?
If you find yourself in
that situation, Vennster Managing Partner Ronald van Luttikhuizen
advises adaptability when it comes to tools. “Especially if you’re a consultant
working for various clients, it greatly helps to use the tooling that is
available and already in use by clients and stakeholders, instead of rigidly
sticking to your own toolset,” says this Oracle ACE Director.
That can mean
dealing with a variety of Unified Modeling Language (UML), Business
Process Model and Notation (BPMN), and other modeling and design
tools. As for his personal favorite, van Luttikhuizen also lists Sparx
Systems’ Enterprise Architect. “A great tool at a great price,” he says.
But van Luttikhuizen’s
toolbox also contains some more-basic applications to help him get his message
across. “In the end, architecture is about communication,” he says. “So in the
beginning of an architecture-oriented project, the most important tools are a
whiteboard, Microsoft PowerPoint, and Microsoft Word.”
Karina Ishkhanova,
a solution architect and technical lead for payment systems at School-Day
Solutions, agrees with van Luttikhuizen about the importance of basic
communication tools. “The first stage in defining the future architecture
happens in close collaboration with business departments,” she says.
“Whiteboards, paper, and markers are indispensable. Sometimes we even cut paper
into components to move them around to help visualize the variations on
proximity to other system parts.”
For
modeling, Ishkhanova uses UMlet, an open source UML tool, which
she values for its simplicity. “At more-advanced stages, I move to Oracle
JDeveloper,” she says, “to take advantage of its integration and automation
features.”
Communication tools are
also vital for Lambda Software President Aki Iskandar.
“By far the most
important tool in my toolbox is the one that I ask my clients to hand to me
before any discussions, let alone architectural work, starts. It’s the set of
three blueprint documents that jointly define well-articulated and complete
business requirements, the constraints within the environment, and the
architectural diagrams for network topologies,” Iskandar says. “Without
them, you may overarchitect or underarchitect the system. You
can’t architect a system without knowing the constraints before you start.”
Perhaps his last point
is the IT architect’s equivalent of the carpentry maxim “Measure twice, cut
once.”
While the choice of
tools varies among these four architects, that choice is driven by the shared
goal of effective communication in order to ensure a good fit between the
up-front plan and the completed project. Isn’t that what IT architecture is all
about?
