By Brian Lucas
Agile concepts, techniques and technologies are much in demand today. Many organizations have astounding success with agile, while others experience failure, sometimes horrifically. Usually agile fails in these cases from improper application of the concepts or lack of supporting environments. While agile necessarily implies “rapid”, at least as far as iterations are concerned; it doesn’t mean poor quality. However, constant code changes to improve quality can bring a development effort to its knees; particularly when you are dealing with large scale efforts involving multiple teams. Refactoring, a concept that is embraced in agile, can include very negative maintenance aspects. After all you want to spend your resources developing vital new business functions not maintaining existing code without changing function. How can you build longevity and scalability into your agile efforts while minimizing refactoring and insulating them from technology changes? The answer is you need to adopt agile architectures!
There is a notion that strategic architectures and agile concepts are incompatible and that the I/T professionals in each camp are so different they cannot work together. On the surface this seems valid, but if you think outside the box, the solution is really only a matter of perspective and lies in the need to impose the requirement of supporting agility on these architectural constructs.
What is the concept of an architecture and why are architectures important. Let’s take a simple example. How many of you have ever put a puzzle together? Did you just start putting pieces together in any old fashion? Did you select a good location to put it together in? One where you could work and not have the puzzle constantly disturbed? Did you have help and were they helpful? How long did it take you? Did you have to move pieces around a lot? Did this approach take a long time and was it frustrating? Did you finally give up and throw the puzzle away? Or instead, did you try to find all the straight pieces first and assemble the border? Did you sneak a peek at the picture on the box? Did you try to find all the pieces for the red barn and put them together next? If you didn’t put the barn together in the spot where it belonged, did it fall apart when you moved it and you ended up having to put major parts of it back together? If you put the barn and the stream together in the right spots didn’t it save you a lot of time and effort?
This is what good architectures are all about, particularly agile ones. They put the borders together to establish your systems’ flight envelops. They sneak peeks at the picture on the box to establish strategic enterprise vision for your information systems. They intelligently think about the environment where you are going to put the puzzle together to select the development and production environments and technologies that make your efforts easier and more efficient. Architectures are strategic guides which show you where elements should reside and shape your development efforts without causing onerous restrictions.
Architectures are generally wrapped in an enterprise architectural (EA) methodology. There have been a great many attempts at establishing various EAs since the concept was born over 20 years ago by John Zachman. The vast majority of firms today use either the Zachman Framework for Enterprise Architectures (ZFEA), the Open Group Architectural Framework (TOGAF), the Federal Enterprise Architecture or the Gartner Methodology (GM). Each has their own advantages and disadvantages. Not being a purist, I like to use a combination of three of them: the ZFEA which has the value of great multiple perspectives, the TOGAF which complements the ZFEA nicely and to which I add a fifth architectural construct I call a system architecture, and the GM which embraces the concept of where you are going is more important than where you are. For now just accept the fact that you can be eclectic with architectures and pick the good points of more than one and combine them. That is after all being adaptive, which is a principle agile concept.
In TOGAF terms, there are four complimentary architectures your organization needs to make any of your development successful. They are a business architecture, an application architecture, a data architecture and a technical architecture. I add a fifth called a system architecture. Put simply, a system architecture is the background or foundation in which you detail the structural implementation of an application architecture in order to meet the business architecture needs through technical and data architectures. Business, application, data and technical architectures are familiar to most CIOs and I/T personnel. It is the agile requirement and indeed imperative that makes them dramatically different from their historical representations. Agile is this case doesn’t mean that the architectures have to change constantly with the changing business needs. It means that the architectures are flexible enough to readily accommodate changing business needs without changing themselves. This gives stability to the development effort and minimizes or eliminates negative refactoring.
An agile architecture limits total cost of ownership by enhancing flexibility as a means of evolving its contents with changing business needs without changing its structure in order to eliminate negative refactoring.
A brief comment on technology; too many confuse technology and architecture. It is a fact that technology can provide a tremendous advantage and keeping current is generally a good idea. However, too many reach for technology as a solution to all ills, including bad design and weak architectures. Throwing more hardware at the problem or upgrading the software technology is a Band-Aid on the cancer that will eventually kill your application, your information system’s viability or worse your entire organization. Further compounding the problem, a poor architecture will often prevent you from maximizing the benefits of the latest technology.
So now you understand the importance of architecture and know that strategic architectures did not go out the window with agile development. In fact, they became more important and unfortunately more difficult to construct. Maximizing your success with agile software development means addressing agile concepts from an architectural perspective. To learn about the technical aspects of an agile system architecture read my article, Agile System Architectures. I will cover the other aspects for a complete formulation of an agile enterprise architecture in additional articles, and till next time, keep agile!
 Code refactoring in its purest form is a highly disciplined technique for restructuring an existing body of code, modifying the internal structure without changing any external behavior. This is driven by the need to improve aspects of the software that are not directly related to business function. This is done through refactorings, which are independent discrete changes to the code designed to correct an undesirable technical issue. Philosophically, refactoring’s advantages include improved code readability, reduced complexity, better maintainability and a more demonstrable internal architecture. I call this “positive refactoring”. Unfortunately, refactoring often is not discrete, involves large changes, propagates change across large numbers of objects or classes and spills into functional areas. When people say refactoring, they often include this second set of descriptions in their definition. I call this “negative refactoring”.
 Having the right organization structure or organization architecture is covered in my article, The Imperative of having an Agile Organization Structure.
 Does this sound like traditional software development?
 According to The Standish Group’s Chaos Report which surveyed 13,522 projects, unqualified project successes are only 34 percent to be exact and outright failures, where projects were abandoned midstream, are at 15 percent.
 Architectures that restrict development and don’t facilitate the rapidity and prototyping that are essential to agile are one of the reasons agile efforts fail. You are trying to be agile in a non-agile environment.