Benefits of the Team Architectural Approach

Run correctly, what does a good software architecture give a development team? For that matter, what does it give to the entire organization surrounding the souls trying to develop software? It is certainly expensive and time consuming. There are no guarantees that ROI will be enough to justify it. Then, of course, a good manager can't help but notice that every developer in his charge has a different definition of architecture and, for some, no definition at all.

Let me take you into my world and show you, dear reader, what it means to have an architecture. That is to say, a software application architecture that is associated with a framework based on simple development patterns. (Design patterns are fine for IT organizations that wish to justify their own existence. Development patterns are for getting the heavy lifting done.)

My Team:
Chuck: Architect
Richard: Business Analyst
Myles: Senior Developer
Sharon: Developer
Mike: Developer
Noah: Junior Developer
Kelley: Quality Assurance and Testing

There are others but they mostly just count the beans and bullets.

Richard has completed his first draft of the business and functional requirements. These are passed off to Chuck who goes into a cave to read them unimpeded. When he returns, he has lots of questions, mostly about implementation of specific requirements or the delta of one part of the requirements to another. These questions answered, he tracks down Myles for some design session madness. By the way, if Richard is worth is salt, he has provided Chuck with some prototypes as well to show off what the client expects the application to look like. Chuck and Myles go to town with:

1. Their existing architectural patterns
2. The overall understanding of the system parameters
3. The prototypes
4. A listing of the most difficult (or complex) challenges the application must address

Step 1 is determining the patterns. Chuck and Myles have patterns for listing data, searching data, editing single record entities, editing lists, navigation control, business rule validation, state management, security and a short stack of other things. Each of these development patterns has its inputs, outputs, event model and templates defined so they know exactly what each is used for and, more importantly, what each is NOT used for.

Chuck and Myles go through the requirements and categorize each screen or section of the application into the development patterns it will use. Anything that does not fit an existing pattern is the 20 side of 80/20 and is set aside for independent address later on.

Step 2 is the decision-making process to decide what to do with the 20% non-pattern entities. Each is evaluated to determine if it is truly a one-off or if the solution may generally happen again in another system. If the former, the item is assigned to Myles for development. If the latter, Myles and Chuck perform an independent design session to determine a new pattern to be added to the list. Myles codes the piece according to the pattern and his work becomes version 1 of the template for that pattern.

Step 3 is the review with Richard, Chuck and Myles. In this session, Myles and Chuck review how each interface will actually work with Richard. Richard can then either determine that a particular methodology will not work or adjust requirements to support the design. Richard can now flesh out the business and functional details of the rest of the application knowing how each piece will interact with others and how they will function as a unit.

Step 4 is the "final" requirements review with Chuck, Richard and Myles. At this time, all portions of the application will have been completely discovered and the functionality expected will be recorded. Chuck and Myles will go back into the cave to finalize the details of all interfaces. Everything must be covered.

Step 5 is assignment. Chuck divides sections of the application by pattern between Myles, Sharon, Mike and Noah. Patterns are assigned based on their inherent complexity compared to the experience of the developer. When a developer has not encountered a pattern they are responsible for, they will review the design documentation and templates for that pattern based on the platform (win/web) and proceed.

Step 6 is initial development. This stage of the application is more about data gathering than getting work done. Each team member is tasked with estimating how long an item of a specific pattern will take. He then actually develops and internally tests it until it is complete. When complete, he reports back to Chuck with the time it took. That developer should also understand the +/- factor of how long a more or less difficult implementation should change that base time estimate. It should also be expected that as the developer works more items, he will become more proficient at it. Sort of a software factory (heh).

Step 7 is real development. Chuck has baselines for all patterns for all developers. He can now plan how long the development phase will take with reasonable accuracy and granularity. Each developer knows how to do their job and only the skyline issues are raised to Chuck or Myles for decision making. When complete, each task is reported back (with development times) to Chuck who adjusts the schedule as appropriate. When a task is reported complete, Chuck will also review the average time that developer is taking to do that job and determine if the base estimates are still reasonable.

Step 8 is QA. Kelly understands the requirements and the patterns. She knows that there are very specific rules as to how the parts of the system can interact. Therefore, her first task is to smoke test the entire application looking for things that do not conform to known patterns. When she finds something, she tests this as early as possible in her cycle. This allows the highest risk portions of the application to get back to the developers for bug fixes as early as possible.

Kelly then continues to test the application in logical fashion and, when defects are found, they are directed to the developer who worked each one. The time to bug fix an item is added to the time estimate to perform the development of that pattern. Then, in future versions of that architecture, Chuck can raise a flag when a developer finished a given interface of a specific pattern much too early and QA it in development himself. The result may be that a developer is just that good or it may be that he is lazy.

Simple, no? Looks good on paper. The real trick here is getting everyone singing the same music at the same time. Well, that and figuring out what to do when you start with no development patterns at all...

On Architecture

When does the definition of a thing become more than the thing itself? Twenty years ago no one cared about software architecture. Now, when you review how the community defines architecture, its sometimes insightful and sometimes laughable. It is seldom consistent and often vague. It's a great title though.

The problem is that architecture is similar to art. When there is talent and thought involved, people notice. When you throw it against a wall and it sticks, it is not necessarily art (or architecture). Who defines it is as important as the definition.

So here goes...

When defined by its results, application architecture is successful when it:

1. Defines the patterns of all entities within a 'system'. This accomplishes improved project estimation and allows for specialization of development staff.
2. Defines specifically HOW each entity can interact with other entities and which entities cannot interact. This accomplishes loose coupling.
3. Defines WHEN each entity can communicate and what information is transferred during a transactional communication. This provides state management and requirements coverage in all application scenarios.

An entity is the realization of an atomic unit of the business problem that can be logically and clearly separated by its composition, function or derivation.

When all three of these objectives are met, the application’s architecture can be completely documented and translated into tangible components and base objects that enforce requirements within context.

... chew on that and let me know what you think. JJ