TOGAF & Software Architecture

Edited on 13/12/5

I recently obtained the TOGAF Foundation Certification. That’s nice to be successful at first time with a certification exam, my first exam since at least 25 years! I’ll talk about TOGAF in other posts but, you know, when you just learned something new and discovered a new part of the world you tend to view everything from this new viewpoint. That’s why I unfortunately introduced TOGAF in a conversation where it did not have to take place:

Software Architecture is not Enterprise Architecture. That is a sure point because a Software is not an Enterprise. But… what is the point to speak about Software Architecture modeling if no Enterprise Architecture has been defined, and eventually modeled, to contain this Software Architecture? Does Software Architecture bring sufficient value by itself to justify working on modeling it? By the way, what is exactly an Architecture? And what is a Software Architecture?

I must admit that, although having been myself a Software Architect for some years and maybe still being, the concept of “Architecture” has never been fully clear for me. Nor for anybody I worked with. Just always been sure that this concept was relative to the way things are related one to another, but how to put this on firm grounds?
Then, thanks to my TOGAF learning session, I discovered the Grail of Architecture definition, borrowed to ISO/IEC 42010:2007: “The fundamental organization of a system, embodied in its components, their relationship to each over and the environment, and the principles governing its design and evolution”.
The TOGAF extended definition is also interesting: “A formal description of a system, or a detailed plan of the system at a component level to guide its implementation AND/OR The structure of components, their inter-relationships, and the principles and guidelines governing their design and evolution over time”.

That is to say that Architecture has two faces: the material way things are related, and an abstract plan for this material reality. Wahou. Sounds nice!.. but also a bit weird, isn’t it?

Back to Software Architecture. Needless to say, one can easily understand that for many IT people source code is, by itself, a perfect Software Architecture. Source code perfectly describes what is the software system: executable code is, in essence, this source code. And extended source code also self-contains how the system is built: the source code and the build parameters are self-described as they are readable by any developer. I save you the discussion part on differences (or not) between source code and model, and jump directly to a pragmatic conclusion.
Considering that source code can sometimes (!) not be the best “principles and guidelines governing… design and evolution…”, what kind of description do we need to maintain Software and to make it evolving? As usual, it depends on what we want to do.

From a developer standpoint: simple general rules, simple guidelines, templates, samples, technical coaching, will probably do. Kind of a cookbook, provided that it is organized in a very efficient developer’s viewpoint way. Today, the best (and most used) cookbook I know names… Google! The problem with Google is that it does not enforce any Enterprise IT Governance rules. A very efficient alternative to Googling coding names MDD, eventually using an MDA approach. But there are so many issues with a generalized MDD approach that few Enterprises dare to use this way.
Does any Software Architecture modeling may help here? I guess no. At least, not substantially. MDD is kind of using modeling to help developers, isn’t it? I don’t even mention UML here. The problem is not the notation but the adequacy between the potential solution (modeling) and the problem (driving development).

From an architect standpoint, the problem is clearly a bright other one… wait. Or shouldn’t it be?! Speaking of Software, it shouldn’t be another problem: the goal is to maintain and make evolving Software applications. As Software is developed by developers, Architect’s goal should include to guide developers and so forth to provide developers the answers they need.
On another hand, at Enterprise level, we generally need to build some kind of general Software design rules to help savings costs and to be able to move on in an orderly and fast manner. And this IT design rules building is for sure part of the Enterprise Architecture. Here we are in a meta Software level, where Building Blocks (TOGAF wording) are not source code. We are in an area where modeling is a good media. Not sufficient by itself, but good enough to be used.
By the way, the modeling notation that seems to be pushed on by TOGAF names Archimate. But fact is that one can probably achieve the same modeling results with UML and BMPN…

Credits:
– featured image borrowed to http://www.sei.cmu.edu/dependability/consulting/. Nice site full related to this post’s subject
– many thanks to Rich Hilliard ‏(@dJdU) for tweeting me the link to the full ISO definition for the term “Architecture”