I thought I would write this potentially controversial post about how traditional productivity tools such as Microsoft Office (Word, Excel, PowerPoint and Visio) can still play a role in the architecting process.
Whether we like it or not the Office tooling is used throughout the architect community as a tool to describe architectures. This topic comes up quite a bit in my conversations with customers. I still find that the overwhelming majority of enterprises still use productivity tools for architecture design and descriptions. I recently did an informal survey at the Open group Practitioner conference in January. What I found from this informal survey was that 90% of enterprises use these tools day to day for architecture. I found similar results at Gartner EA summit and FSTC EA Forum the year before.
The Enterprise Architecture Toolkit (EATK) is set out to help in this area. It provides a series of templates and add-ins to the productivity tools to enhance the architecting process.
Changing the Way we Describe Architecture Designs
Today many enterprises use the Office tools for different purposes. There isn't a one size fit all. Shown below is how we see many enterprises using the productivity tools.
Traditionally architects have been forced to develop architectures in a restrictive and monolithic way. Meaning that the input mechanisms for architecture require a set of fairly sequential steps in which the information is derived. The question now is; are the existing tools we use for architecting, been outgrown or outdated for the tasks at hand. The answer here is no, the current tools are still used for mainstream development of architectures.
The underlining goal is to change the role of Word from simply a word processor to more of a User Interface (UI) for designing architectures. Applying structured UI concepts to Microsoft Word provide many benefits to the architecture document.
Structured Content – Information can be better described in the document. The reason we want to do this is because of the challenges mentioned regarding how information doesn’t integrate well with process or future design activities. One example is the process of importing a model into an architecture document. Often times we import a picture that represents a model of a specific view point of an architecture. If we had an information model we could specific that the model imported is indeed the logical model, rather than a generic image file.
Extensible – With a little more structure information has meaning and definition. This makes that information extensible to other processes downstream.
Consumable – Abilities to consume external content is also possible with a more structured interface. As an example, if you choose to you could import external architecture information from other systems to automate you design efforts.
Why not a Model Driven Approach?
So the next question that is probably in most of your minds is, what about Model Driven Development (MDD)? Through these same surveys my findings found that MDD as an architectural practice is very difficult. There are a variety of reasons for this:
Education - There is a substantial learning curve to learning an ontology, tools, notations, process, etc. Also, there is the issue of un-learning what you have been doing for so long.
Tooling Maturity - There are a lot of great tools for modeling but these tools are still not as mainstream as they need to be. There are many tools that are proprietary in nature. There needs to be more standards support.
Adoption - Usability and complexity comes into play here. I have seen revolts against a structured modeling tool because it wasn't as intuitive or easier to learn as other shape (not modeling) based tools.
Does this mean that we not go down the MDD approach? Of course not. We just have some challenges to overcome. To overcome these challenges we need to take a pragmatic and iterative approach.
Meaning, not all organizations are ready for the MDD approach right away. For these organizations they should take a "baby steps" towards MDD. The big bang approach has proven to be a painful and perilous route to take when trying to change how an organization develops.
If an organization is ready for a MDD approach, that's great and should do so. The role of documents changes again, right? Of course, now the document can be used as a report or can be used to describe the models at the meta level. The role may become smaller but still can play a role.
Comments