Description

Tools are essential to carry out the activities defined under “software 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 Software 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:

https://en.wikipedia.org/wiki/Software_architecture

  • Software 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.

Overview

Why does an architect need software 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?

software_tools1

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.

software_tools2

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.

software_tools3

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

 software_tools4

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.

software_tools5

 

 

software_tools6

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.)

Sub-Capabilities

Software Architecture Tool Identification

Understand and is aware of importance of using a set of defined tools in works related to software architecture, its advantages, and is knowledgeable to adopt use.  Understands the need for multi-dimensions of use and need for software architecture tool, its importance in integrating and cohesive approach.

Software Architecture Tool Evaluation for Engagement, Role and Environment

Knows the available software architecture tools in the market and in open source and has capability and has adopted one or more of them in actual work related to software architecture, has the basic ability to evaluate the advantage and disadvantage of use of set of tools or combination of them for the environment, engagement and role of software architecture.

Integrated Use of Various Tools in Cohesion for Best Benefits to Architecture Work

Has the expertise to evaluate across the dimensions for few of the pillars of iasa in any engagement, has ability to advise and recommend use of architecture tools with right blend and cohesiveness. Is able to adopt the tools in having prior experience in using two or more of the available set of tools or combination in their work and correlate to the organization while carrying out the software architecture practice.

Recommending Best Practices and Enterprise-wide Profiling of Tools for Practice

Ability of having used and adopted multiple tools in practice. Has the ability to do a value based assessment of set of tools, recommend and use them in the actual work of software architecture. Ability to suggest and recommend a best practice in terms of specific environment, keeping in mind all the dimensions of requirement, including the 5 pillars of Iasa and in most of the engagement models / roles of the software architect. Is able to evaluate qualitatively and compare and contrast the tools capabilities, is able to suggest integration and reuse of data, process, domain flows in the use of these tools.

Resources

Iasa IT Architecture Body of Knowledge (ITABoK) – http://www.iasaglobal.org/itabok/

 

Author

vinu jade

Vinu Jade
Enterprise Architect – jDruids

In 25+ years of work experience, Mr. Vinu Jade, a practicing Enterprise Architect at jDruids presently, has held leadership roles including Technology Advisor, and Chief Architect & Technology Officer at Major Automotives in United States as well as India. He presently heads the IASA India Operations as its Chapter Lead and Ambassador. He is involved in Strategic directions to Banks and regulatory boards in APAC.

In recent past, he was Chief Enterprise Architect at Asia’s Largest Banks in China, and Malaysia. He has worked as Head of Corporate Technology Group, leading Enterprise Architecture, in Asia’s Largest IT Systems Integrator. He has worked an Advisor to CIO at South Africa’s Large transport Enterprise. He has experience in working in Telecommunication, Hospitality & Hi tech industries in a strategic role for driving IT organization.

He is an expert in providing corporate level practical Enterprise Architecture Orientation to large number of senior architects at major System Integrators, Banks and Automotive organizations in India, United States and APAC, adopting IASA Methodology and leading EA frameworks. He has been a part of Academic Advisory council for Computer & Software Architecture in universities in United States and India.