Tools are essential to carry out the activities defined under architecture work. For Decades this area is partly evolved not cohesive and complete though there are few Gartner and other analyst defined EA tools and Design Tools for UML, OOAD, etc in silos.

Much has progressed in defining the standards for architecture practices with languages, formats and frameworks being adopted, which is a positive in this field. Various Frameworks in vogue have defined the architecture tools, based on their definition of what architecture covers. Analysts and Practitioners view points and usage has been well published – IASA Definition is very clear and has focus on Practice in varying contexts, scope, width and depth of activities that go across intra and inter enterprise boundaries.

Here is a Wikipedia definition for getting some views from the world of architects, and can derive the scope – Width and Depth of capability of a software architecture tool must have:

  • Architecture is Scope, Characteristics and motivation for Software systems and Architecture Activities such as Analysis, Synthesis and Evaluation are primary activities.
  • Design, Reasoning, Decisions, View Points, Styles and Patterns based on the above meta driven definition are the kind of work that the practitioner will do. Hence the tools must cover the above from a generic point of view.


Why does an architect need architecture tools?

Various available and published approaches have focused on need of tool to achieve

  • Conceptualization
  • Definition or Design of Architecture
  • Evaluate and Evolve the architecture
  • Document the architecture
  • and Analyze the architecture

IASA definition focuses on Multi Dimensional Set that drives the software architecture practice, much wider impact, propose to be cohesive approach as elaborated in subsequent sections. IASA believes, In an environment of collaboration, based on 5 Pillars, the kind of engagement the architect has with the organization and the role they have is very important and need to be addressed by any software architecture “set of“ tools. IASA assesses at present in the market, there is NO ONE such tool, and a combination or “SET OF” integrated tools are needed for an effective practice.

Software architects role and responsibilities are often multi dimensional in their nature and differ in context.

What are the Dimensions involved in need for tool?

The three dimensions that define the need for use of Software Architecture Tools are:

The First dimension for Architects Practice is adopting Software Architecture Tools as needed for their Roles and related Deliverables. This dimension involve the role being as Business, Software, Solutions, Information, Infrastructure Architects and sub sets of them such as Domain, Data, Technology, Systems or Product Architects

The Second Dimension is the Engagement Model, in Scope, Context and bringing essential value, keeping in for the Organization Engagement Entry Points (These lead to Assessment, Analysis, Model, etc based on Entry points).

The Engagement model involves Scope, Context, Value Driven Engagement such as Business and Strategic Planning, Advisory, review, Architecture communication, Portfolio Assessment and Prioritization, Technology Framework adoption and review / design etc.

The Third Dimension is in adopting the 5 Pillars of IASA to achieve complete coverage of the width and depth of architecture value to business, both Business and Technological. The 5 Pillars and its Integrated Collaborative Environment (ICE) are Business Technology Strategy, IT Environment, Design, Quality and Human Dynamics

What are the benefits of this approach in choice of software architecture tools?

The responsibility of the Architect often depends on the context of the project in question and how the work is formed. In some engagements the Architect may be responsible for solution architecting with some dimensions of environment such as BTS and or Design while in other engagement the Architect may provide a supporting role to other roles as a Technical Architect or infrastructure architect.

Strength: This approach enable the choice of right tools that can help in practice, without restricting or over relaying on few tools

Threat : This will essentially need an integration between various tools and is best solved by adopting to Standards based tools, which follow Eclipse, Common Library, Standard of Language ( BPEL, DDL etc) and help in translate the data between them via common formats ( XML, etc)

Opportunity: For the industry to become cohesive to provide the best fitment of tools to an architecture practitioner, by integrating with standards as above, and bring reuse and reduce redundancy of work and data loss in work

How are the tools used by the architect in daily activities?


The Architect would be expected to be able to evaluate the use of right tools for the delivery based on their role and engagement. A mature role that is having the width is as an Enterprise Architect. They may not have much depth in carrying out doing specifically all the engagement level works, but clearly, They understand and can drive the architecture engagement with niche specific SME in the areas.


Other roles may go an extra mile of effort in the depth of engagement in the team, specific to solution, or information or infrastructure, but may not cover the compete enterprise. This width of role and depth of engagement depends on the effective approach that one has in the environment of collaboration between the 5 Pillars.

Iasa Software Architecture Tool Box

The IASA Tool Box ideally not uniform in concept. It varies based on 3 dimensions in Width, Depth and Height!. It has to be varied depths and width, but the rectangular tools box represents the concept of various dimensions and how it gets adopted as a SET of TOOLS.

It defines clearly that the SET OF TOOLS for software architecting must cater to the three dimensions and depends heavily on how WELL THEY integrates and PROVIDES cohesiveness. The SET OF TOOLS must work together conforming to industry standards for interoperability and data reuse, continuity in Assessment, Process, Domain and Governance Model.


Architecture Dimensions to Map Tool Requirements

In mapping the 1st Dimension at Engagement Level to the essential features of a software tool, specific engagement specific activities are highlighted in the following to aid architect to perceive and evaluate them. The engagement needs are identified for each sub activities in each of the 5 Pillars of IASA


In mapping the 2nd Dimension at Engagement Level to the essential features of a software tool, specific engagement specific activities are highlighted in the following to aid architect to perceive and evaluate them. The engagement needs are identified for each sub activities in each of the 5 Pillars of IASA.





The Engagement level Map with Role and 5 Pillars help define clearly the activities that are essential for the architect

The Map Dimensions detail the framework for evaluation and choice of tools in the market or open source for specific practitioner need

As stated earlier, choice depends on an integrated cohesive “set of “ tools and not ONE. It also clearly defines a statement of adherence to Standards and Best Practices for easy interoperability, Integration between the tools – Format, Language, Model, ( BPEL, DDL, XML for e.g.)