Architecture Frameworks, Handy as a Pocket on a Shirt or As Welcome as a Fly in a Biscuit?

A few years ago, I was talking with a colleague at Duke Energy in Charlotte, NC about what he does on a daily basis as a software architect.  He gives me the usual answer about meetings and donuts and drawing boxes.  Then, he starts talking about Enterprise Architecture (EA) and how great it is and how I should learn it until basically I asked him for his driver's license to make sure his name wasn't Oral. (Yes, I know he's dead.  Too soon?  Oral, not the Architect)

I did a little research into what was going on with the various frameworks (EA, DODAF, FEAF, MODAF, TOGAF, Zachman).  What I found was, at a high level, they are only good for documentation.  EA and TOGAF actually give you some large boxes on where to put your code, but Zachman, DODAF, FEAF and MODAF just show you how to organize your thoughts and plan for the movement and integration of data.

So you framework people are telling me that I need help conceptualizing the solution, not actually designing and building it?  No wonder nobody seems to be able to get things done.  As a kid, I thought we'd be in the Star Trek Universe by now, where people were freed from the drudgery of work and making a living because the computers were doing all the heavy lifting, freeing us to think and innovate, to solve really interesting problems instead of producing widgets or TPS reports with or without the correct cover sheet.  Instead, we have spreadsheets and email and business as usual, the same as it was in 1843, except that Bob Cratchit doesn't have ink stains on his fingers and he can email his spreadsheets to old Ebeneezer instead of hoofing them over.  Sometimes they do still hoof them over.  We call that SneakerNet.  NikeNet if it's a really good network.

So today, I came across Paul Preiss' article "Why Frameworks Are Killing Architecture" and I thought, 'finally,someone who gets it.  Paul does get it, kind of.  Here are his five reasons he states NOT to use an Architectural Framework:

1. Frameworks get in the way of innovation
2. Frameworks put the focus on deliverable instead of outcome
3. Frameworks create poorly skilled architects
4. Frameworks make hiring architects more difficult
5. Frameworks allow architects to keep 'killing patients'

I've linked to the article so you can research that last one yourself.  He then goes on to explain why you should simply change your approach to AFs:

1. Move to only working with individuals who a have achieved an experience based certification in architecture
2. Optionally pay for the personal development roadmap of your current people, not your future staff
3. Measure your architects based on business outcomes
4. Start measuring outcomes related to design decisions and share results

Well, you had me at the first five.  "Measure architects based on outcomes" is a great thing to do, but the people cutting the checks can't see or understand the design decisions and the reasons that they are made, so that kills  the only one that really made any sense, number 4, pay for performance.  Which brings me to the conclusion: Either you can write the code, or you can't.  If you can't write the code, AFs are a really good way for you to get away with drawing boxes, attending meetings, eating donuts all day and getting nothing accomplished while drawing a paycheck.

If you've been following along, you know that only once have we pointed out a problem without offering a solution.  Here is what we replace these Architectural Frameworks with:

1. Identify the entities in the Enterprise, like employees, structures, capital assets, processes and everything else
2. Identify the attributes of the entities, last name, date of purchase, hours run and everything else
3. Identify the relationships between these entities, basically either one to one or one to many.
4. Identify the desired outputs such as production reports, P&L, purchases, sales and even tax returns. We will no longer be producing TPS reports, with or without the correct cover sheet.

Build a database that contains all the entities, their attributes and relationships.  Design and build a piece of software that looks at this database and builds a middle tier to support Create, Read, Update, Delete and Search (CRUDS (CRUD + Search)) and looking at related data in this database.  If we have a database table of students and a database table of classes we need to generate the code to get a list of classes for each student and a list of students given a ClassID automatically.  We don't want our developers to write that mundane stuff.  Read all about developers a little below.  Design and build a tool to generate a User Interface (UI) based on the generated middle tier.

So here is the thing about developers.  They are worse than cats and getting them to all run the same direction at the same time and at the same speed is quite a bit more challenging.  They are always (collectively) the smartest guy in the room.  ...even when they aren't.  It is a reputation they earned and are used to so they do what they like usually, and if you don't like it, what they built is better than what you asked for anyway.  ...except when it isn't.  I gave a group of junior developers a completed database middle tier and part of a user interface (as an example of what I wanted) to complete. After several weeks I demanded to see what they were doing (they didn't want to show unfinished work) and was shocked to find they had not followed instructions but had written an entirely new middle tier and added several tables.  needless to say, these developers are no longer drawing paychecks.  Just as bad is the fact that nobody, ever wrote an application according to best practices 100% through and through.  Worse is when the technology changes or you have to add or update features, you get a new set of developers that don't know and don't care what the former developers did, and will tell you that it's wrong in any case, that the whole thing needs to be scrapped and started from scratch.  The only way to adhere to best practices at all times is to generate the code.  You have to do it for the developers and let them unleash their creativity on the User Interface.  If you have a brain in your head, you simply give them a picture of the UI and tell them to write the HTML, JavaScript and jQuery to get it done.   

There are tons of tools out there to generate the middle tier, and I dislike them all.  (N)Hibernate and Entity Framework immediately come to mind but I don't like them because they create big, mysterious 'black boxes' that work black magic and might end up in possession of your soul at the end of the contract.  You can't see what SQL is getting generated and what it is doing to your database.  If you have performance problems, and you will, there is literally no way to solve them.  Further, it is a security nightmare since the tables are opened up to the generated SQL they produce.  This also opens the tables to hackers and what are called SQL Injection Attacks.  We built a tool that uses Stored Procedures exclusively and locks down the tables to anyone who doesn't wear the System Administrator's underwear.  Or shave his ugly mug in the morning.  That's not mean, I'm the System  Administrator.  Mostly.

We have a tool to consume our generated middle tier on the desktop and Microsoft was generous enough to build a tool that creates MVC web forms based on the generated Model (middle tier) from above.  Given a good database design, we can generate about 80% of a new application.  The other 20% is making it pretty and adding visual gewgaws like datepickers and modal dialogs for additional input or information.  That part of the development can be handled by a junior developer.

This does a couple of things for us.  We have the ability now to generate ONE piece of software  to run the enterprise.  Think of the traveling salesman problem.  As the number of stops increases, the time to come up with the best route increases.  As the number of stops approaches infinity, the time to calculate a solution also approaches infinity.  Until you generate the solution.  That makes the ONE piece of software conceivable and even buildable.  Further, since the framework is followed to the letter, this obviates the need for Zachman, DODAF, FEAF and MODAF becuase they are about figuring out where the data sits and integrating it.  If we generate the code, we already have a framework that we might describe with the other two, EA and TOGAF, and since everything is done the same way, every time, we need minimal documentation which is really what they are meant to produce. Additionally, if we find later that we made a mistake, or we found a better way to do things, we change the structure of the database or we simply need a new version, we simply reconfigure the code generator and regenerate the middle tier.  

Here at Sentia Systems We are moving away from an object oriented (OO) middle tier where adding a member to a collection adds it to the database, to a hybrid OO/Dependency Injection (DI) middle tier where if we want to use DI, we can but otherwise the default OO solution continues to work.  When we pull that trigger, we'll regenerate the middle tier and nobody will ever know that they have a completely redesigned and rebuilt middle tier (about 65-70% of the application), it will just continue to work, just with the new DI capabilities.

So yes, Frameworks ARE killing Architecture.  If you are a junior guy, you are probably going to use Access or loop through records in Java or make whatever other mistakes junior developers make, but you don't need a framework for that.  If you are a senior guy, you don't need the frameworks getting in the way of doing the real heavy lifting of design and development and so some MBA feels better about hiring you to do something he doesn't understand.  If you are about producing documentation, reams of paper, to tell you what was done and how it was done, nobody needs you.  That stuff isn't even read most of the time, and doing things the exact same way, every time eliminates the need for that anyway.

The conclusion is that frameworks don't add value and they don't write software.  They are a solution looking for a problem.