Moving from Software Architecture to Enterprise Architecture

Yesterday I visited a customer of ours. He showed me the possibilities of using Lattix together with Troux and in the mean time showed me more on Enterprise Architecture. So today I surfed some websites to get a better understanding of Enterprise Architecture.

In many cases Enterprise Architecture and Software Architecture do not differ much especially if you have at least some knowledge of IEEE1471 and the Views and Perspectives approach. Enterprise Architecture can be described by using different EA Frameworks. Since there are a lot I needed some comparison between those frameworks. I found a very nice whitepaper here.

This paper contains an introductory case in combination with the applicability of the frameworks in support of this case.

Scalabilty guidelines

Randy Shoup of E-Bay has written a very helpful arcticle on architecting for scalability. You can find his introductory article here.

Models for Evaluating and Improving Architecture Competence

Len Bass, Paul Clements, Rick Kazman and Mark Klein have written a very interesting technical report on Competences of software architects and organisations.

You can download the document from here.

Mindmaps

Problem area:

Mindmaps are especially useful in situations that are not particular clear. By making a mindmap one structures information and by doing so start to better understand the information. E.g. combining information found on different websites, but with the same focus point.

Mindmaps not only help to structure knowledge, but also makes it possible to better remind the information. Mindmaps are particular valuable when they contain less words and many images.

I use mindmaps in many situations. In many cases I use the technique as a starting point for a new document, planning, presentation or website. Mindmaps force you to structure the information you want to present. Basically I use mindmaps when I am not sure what to do next or approach new information.

Tool support:
For Mindmapping many tools are available. Some are free such as Freemind, other commercial such as Mindmanager and Mindmapper. For me tools that can export mindmaps to Word, PowerPoint or similar formats reduce the time to create a new document.

Concept maps

Problem area:

In cases that you notice that people within your team or with people outside your team are miscommunicating, for instance:

• because the concepts are unclear,
• the exact meaning of words differs from person to person, or
• a kind of project/domain glossary is lacking,

it is wise to start using a concept map. Making a concept map can be a good starting point for requirements gathering sessions/design sessions and so on. On the other hand making a concept map can be very helpful for you.

In a concept map nouns and verbs are connected to each other since verbs connect nouns. Nouns will become dependent upon each other and start to make sense. A concept map is a perfect way to start modeling (e.g. in UML class/ERD diagrams) afterwards.

I have used concept maps for more than one project. Basically I start to make concept maps if I want to get insight in a particular domain and want to find out if the team members and stakeholder have the same understanding of the domain (and mean the same with it).

Hierarchical concept maps (read pyramid shaped) are easiest to understand and easier to build (software) systems with. Focus of a concept map can better be on the domain layer or the datamodel.

Tool support:

A nice tool, called CmapTool, to use can be found at: IHMC with this tool it is possible to set-up a concept map server that enables teams to work on a single map. It supports auto-lay outing that is helpful when concept maps start to grow.

Currently I am not aware of other tools since in many situations this tool is doing what it is supposed to do, and it is free. You are welcome to introduce other tools here.

Interesting introduction to Software Architecture Refactoring by Dr. Michael Stal

I just saw an interesting movie on Software Architecture Refactoring by Dr. Michael Stal.
Michael Stal On Architecture Refactoring

Michael discusses the current state of refactoring, which is most of the time on code level or derived from code.

Michael also has a blog at blogspot.

Upcoming Seminar on Software Architecture in the Netherlands

Together with some partners we will organise a special one-day seminar that will demonstrate tools for visualisation of source code. Both vendor and user will present their findings and usage of these tools. A date and agenda is not set yet. Vendors and software architects that use these tools are invited and can contact me.

The tools should be useful to provide insight into architectural aspects as derived from source code. One can think about special visualisation, legacy reverse engineering, architectural control, etc.

The seminar will be targeted to experienced software architects only. The seminar will probably located in the vicinity of Eindhoven.

Viewpoints and Perspectives

Yesterday I was talking to a former colleague of mine. We were discussing recently read software architecture books. He showed me some heavy stuff about legacy refactoring. I adviced him to read the book: “Software Systems Architecture, Working with stakeholders using viewpoints and perspectives” by Nick Rozanski and Eoin Woods. This book is a great read and very helpful. The book is accompanied by a very informative website: http://www.viewpoints-and-perspectives.info. If you are a software architect struggling with various concerns of various stakeholders the theory and the practical advice of the authors might be very helpful to you. My former colleague bought it with one click.

I work with the IEEE1471 guidelines and the ideas of the 4+1 view for software architecture some years now, but the information provided by Nick and Eoin makes everything more tangible.

Helpful links for further investigation on DSM

DSMs can also be applied in other ways. This post provides links to other interesting material.

Software architecture oriented:

• "Assessment and improvement of Software Architecture" Han van Roosmalen Presentation and paper on DSM Conference 2007.

Project/process organisation:

• "A Structured Approach to Form Dependency Structure Matrix for Construction Projects" J. Uma Maheswari, and Koshy Varghese. This paper discusses the role the DSM can play during a construction process.
• "Applying the Design Structure Matrix (DSM) Technique to NASA Organizational Design" Keith L. Woodman, Vincent J. Bilardo Jr.
  

Project Management Related:

• "An Introduction to Modeling and Analyzing Complex Product Development Processes Using the Design Structure Matrix (DSM) Method" Ali A. Yassine. This paper provides a very good starter for understanding the usage of DSM in process management.
  
• "PD Project Cost, Schedule, and Risk Management Using the Design Structure Matrix (DSM)" Tyson R. Browning. This presentation clearly discusses to applicability of the DSM for project management purposes.

Simple Example of a DSM

The DSM above contains the Java classes that make-up an applet for uploading a file via FTP. According to the specifications the file transfer must be resumable.

What I first did was making three layers:

• User Interface
• Logic
• Data access

After that I dragged the classes into the layer they (should) belong to, thereafter I partitioned the DSM, in such a way that the dependencies towards the providing classes appear below diagonal. Luckily this works for most dependencies. I have seen systems where this was less obvious.

The row and column indicated by the same number contain the same sub-system/class. Cells that contain a value >= 1 indicate a dependency (method call, usage of attribute, constructor, include or other). Layered systems only contain dependencies below the diagonal.

Based on the DSM a number of conclusions can be drawn:

1. The Upload logic is too much intertwined with the User Interface code, this can be concluded based on the dependencies between ImageCanvas and SendDialog towards Upload (indicated by 1 and 3) but also in reverse calling order were Upload calls ChooseMediaDialog and SendDialog. This makes the code hard to read and therefore less easy to maintain.
2. There is a cyclic dependency between Upload and Dict. Dict is a dictionary class, so this in itself is already strange. The Upload logic should no have any output to the GUI and thus it is unclear why it should have a dependency with class Dict.
3. Class ChunkedInputStream (strange name, since we would expect an output stream towards the FTP server) is however never used. The first question that arises here is: Is resumable transfer supported by this applet? This however cannot be answered via this DSM, but code inspection shows that the file transfer is (re)placed in Upload and does not support resumable streams in any sense.

The following conclusions can be drawn in this example:

• Creation of an usable DSM takes only a few minutes.
• Intended architecture can be viewed against the realised architecture. Higher level questions can be answered more easy and precise.
• Code inspection can be postponed until the big picture is created. After this is done code inspection is more focussed on the points of interest (in stead of starting with main() and read downwards from there).
• Relatively scattered DSMs tend to be representative for less clean and eroded code.
• One would, based on the name expect that Upload makes calls to the FTPClient(s), this however is not done.

Other information shown in the DSM:

• On the diagonal percentage figures are shown, these represent the relative size of the sub-system/class compared to the overall size.
• The small red triangle indicated a violation of a dependency rule. In this case FTPSecureClient uses and external third party library that was not yet allowed for usage by the architect.

Showing Java Petstore in a DSM

The following example describes the usage of a DSM. The example is based on the Spring JPetstore example. In this DSM both the Java code and the Spring context XML files are shown.

Since the DSM is partitioned automatically, providing sub-systems and classes are shown in the lower triangular.

Well-structured (hierarchical) systems only show dependencies (shown by the numbers in a cell) below the diagonal. Creating a DSM like this only takes a few minutes.

The loaded files that comprise the system must be rearranged in modules and layers before a valuable matrix is created. Based on this matrix one can detected dependecies (interfaces) that break the hierarchical calling sequence.

In the DSM it is possible to zoom in to class-method/attribute level. Tools provide more in-depth information when cells are selected.

DSM for: First Time Right or Refactor with Insight

I came into contact with the Dependency Structure Matrix methodology a couple of years ago. The problem I struggled with was the complexity of the software systems I was working on. In many cases I had architected a nice system based on simple concepts and tried to document it accordingly, but after a couple of weeks the development team started to work on things that in many cases were not in-line with the architectural concepts and structure. Following (and steering) the development at code level was taking more and more time. When I had questions on a specific subject I positioned myself next to the developer and within a few minutes we were digging at code level after clicking on some tab sheets in Eclipse of Visual Studio. Oversight was missing and I can imagine that working in these IDEs can thigthen the vision of many developers. Making something compile is already quite an achievement.

When a friend pointed me to a new generation of tools based on the Dependency Structure Matrix method my first impression was. Woooowwww. This is what I need to get back into control (or better still the developers can now better understand their part of the system).

Since I got involved in the method I quitted my job so I could work (consulting) with the method and start to help all kinds of companies with their struggle to deliver products in time and with sufficient quality.

The DSM method attracted me because of a number of reasons:

• Extremely short learning curve

During a single day session, which consists of a 1 to 2 hour DSM introduction training and 4 to 6 hours hands-on training a software architect and his development team gain enough skills to continue to work with the method and the created DSMs.

• Scalable insight

In contrast with other methods the Dependency Structure Matrix is highly scalable. At top-level the major system structure is shown and from there it is easy to drill down to areas of interest. This way information can be shown in such a way that it will fit on a single monitor.
During all sessions I presented, developers as well as architects as well as project managers were talking the same language. Problem areas were indicated and first draft improvements were discussed.

Lattix

Since a year more tools have embraced the DSM methodology. Still the front-runner is Lattix. Lattix brings a complete toolsuite that not only offers the ability to perform impact analysis, but also makes refactoring scenario (without the need for immediate code changes) and architecture control possible.

Lattix currently supports:

• C/C++
• C#, VB.Net
• Oracle (database and PL/SQL)
• Microsoft SQL server (all versions)
• Sybase SQL
• Java, in combination with Spring and Hibernate
• Delphi Pascal

More languages and databases will be supported in the near future.

Lattix is a Java application and therefore runs on many platforms and even insight a number of IDEs.

For more information on the Lattix product:
Lattix Website

For more information on the DSM methodoloy:
DSM Website