Architecture: What’s in your architecture toolbox?

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?