This blog will cover interesting questions as well as solutions I've come across on the projects I have worked on.

The areas covered here range from knowledge management to optimizing emergent processes and financial accounting in engineering environments. And from the issues around agile methodologies to patterns and emergent software architectures. 

Speaking of agile, I think the practices of Test-Driven Development (TDD), Extreme Programming (XP), as well as Visual Modeling (with parts of UML, might I suggest) are surprisingly underrated. I think TDD is very powerful, although I find it hard to practice it in its pure form, given the restrictions of today's elaborate frameworks with respect to refactoring. I also don't know why visual modeling seems to have grown out of fashion. While I concede that the concept of a user story as a facilitator of communication is very powerful, I have found time and again that an important outcome of a sprint is an updated visual model so that everybody, not only the people who just worked on a story, can see the effects of that work in a greater context. Finally, I think that especially in Agile at Scale, there is a need for striving for a "common model of understanding", for want of a better word. Working code as the outcome of a sprint, as important as it is, cannot be the only important thing. I think we will find that another important outcome of an iteration is a formalised, incremental disambiguation of the language elements used by the people involved. In other words, by the end of an iteration we have to be able to show that we understand each other a little better. 

And yes, although I don't think I can call myself a programmer I do feel the call to impart my thoughts on some programming approaches upon the world. 

SAFe and SAP

I'm currently leading the transition of a global SAP Programme from ASAP 7 to SAFe. Alas, although there are many ideas to share on this subject I have not yet found the time to write them down. I will say this though: SAFe, with all of the attention it gets, is far from providing a coherent framework from which to infer good answers to even the most pertinent questions. It really depends on the experience of your coaches, and especially on the ability of the agile champions in your organization to overcome resistance and to understand and solve true issues when adapting the SAFe framework. A not so small one is, how do you get Feature teams, a thing all agile people love, when your software architecture and the teams in charge of it are highly compartmentalized? I like to think I have come up with an answer. But again, this is just one of the issues facing you when starting such a transition. 

Scaled Agile Framework - Automated Tests for Functional and Non-Functional Requirements

Agile approaches, and SAFe is no exception, emphasize the importance of constant feedback on whether the development efforts are "on track". Usually this means that the requirements are fulfilled in the right quality. And, obviously, this verification has to come cheaply and quickly. So we automate this using some kind of (unit) test framework. 

I don't want to talk about the real-life issues of actually doing this in large environments with lots of legacy code. I will safe that for later. Rather, what concerns me ist that the kind of tests we always talk about when "being agile" seem to be functional tests. 

One of the reasons I appreciate SAFe is that it recognizes the need for architectural work and incorporates it in Agile at Scale. SAFe calls this 'Architectural Runway', based on the fact that just enough architecture has to be there before the Agile Teams can work on the Features necessitating them. 

But how do we ensure that the architecture (conventions, patterns, laws, technologies) is being followed? I think, especially in Agile at Scale, there is a strong need for verifying the teams' work for adherence to architecture, just as there is for verifying the functional correctness of their work. 

This means that there has to be an efficient, i.e. cheap, quick, and repeatable way of doing this. I suppose that rules out having the architects review the code produced by the end of each iteration. The architects I know would applaud this notion. 

Thus, the solution here has to be automation as well. So, assuming that architecture, as defined above, can be articulated in a formalized way, we can use an Architecture Verification Tool which learns these conventions and checks the source code against them. Clearly, this will need to be exemplified (I've always wanted to use that word), and I will do this soon. 

But for the time being, just a rough example: 

Let's assume we want to create an App for iOS/Cocoa (admittedly a feat that has been accomplished a few times already). Let's further assume that our App is to be document based and that our architects have recognized this, as well as the fact that the good people from Apple already have a variant of the good old MVC pattern in place for this very situation. The only thing the architects need to do now is take this from the Apple site, like so...

Document architecture. In this architecture, a document-based application consists of a controller object for the entire application (NSDocumentController), a controller object for each document window (NSWindowController), and an object that combines controller and model roles for each document (NSDocument).

Source: apple developer site 

… and publish it as part of their Architecture Runway. 

Enter our Architecture Verification Tool. Now the tool knows, or rather, its master tells it, that for each view controller mentioned in the markup language of the storyboard, there needs to be a corresponding view controller which has to be an instance of NSWindowController. I know there is one assumption in here, but hey, what are iterations for?

Again: This example is very simplistic, but it shows how acceptance criteria can be inferred from software architecture rules and cast into, well, test statements. For instance, if we want to ensure that our aspiring programmers have not misused the AppDelegate and polluted it with persistence code, we tell them so and then have the tool check for strings like NSPersistentStoreCoordinator in the AppDelegate class definition. I know that quite a few Apple examples actually put persistence code in there, but I'm not the only one who would beg to differ, at least in some cases. Let's say our architects agree with me. 

So, over time this tool, with the help of the architects, the tool expert and, very importantly, the development teams themselves will build up a set of rules against which the code base can be checked in a very time-efficient and inexpensive manner. 

I do think this is indispensable for Agile at Scale. 

Model-Driven Architecture and Agility

This is from a talk I gave at the German Java User Group in Nuremberg (Nürnberg), Germany back in 2010. There is no translation into English. I did this straight after a project where I had the privilege of working with Dr. Robert Mencl. We programmed a code generator in Java. The thing was/is capable of reading a DSL expressed in XMI and generating COBOL code from it. The experience I gained in the process went into this presentation. 

HOW TO USE IT: Just click on the image to move ahead in the presentation. At the moment, this is in QuickTime format only. 

Dieser Browser kann die eingebettete Videodatei nicht abspielen.

© Markus Wagner 2016