Before or after around 1970, software development was an unplanned and often chaotic experience. The computing industry was young, computers were rare, large and expensive. They were incredibly difficult to program. Most applications had simple tasks and were stovepipe applications, unrelated to other applications. There was no point in planning the development of an application. There was also not much meaning in it.

In the 1970s, things were changing. Computers could be programmed to take care of much more complex tasks. To use programmer time well, much more planning was needed but seldom done. The chaos continued, but now on a much higher scale and with much more waste of time and resources.

As a reaction, farsighted software people started to develop formal methodologies for software development. This happened over several decades from about 1970 and into the 1990s. The strategy used was to "copy" the processes used in physical engineering. These were much more formal and based on a longer history than that of software engineering.

Out of this work came the so-called waterfall approaches. These divided the work into distinct phases. No phase could start before the preceding one was complete, signed, and approved. People called them waterfall processes because they looked like waterfalls:

As in a real waterfall, results falls from one level, dropping down to the next. Having dropped down, there was no turning back to the preceding phase. A laid card is a played card, as the saying went.

In some way this was great for the people building the software. They would always know what was expected from them. In a dispute they could point back to what the purchaser had approved in the preceding phase. "Look here, we did what you asked us to do!" But delivering what's really needed was not so easy with this approach.

One reason for this was the time it took to go through the entire process. For nontrivial systems, years was a norm rather than an exception. This was bad, because businesses changed much more often than they used to. Once delivered, at least parts of the system would no longer be relevant. It supported the old ways rather than those the business had changed into.

That bugged the people that started the agile revolution. Today, almost nobody is using waterfall approaches for software development. Continuous delivery is the key to fast and early deliveries and success.

But as in every revolution, something good was lost in the transmission.

In the early days of agile development, many saw architecture as a thing of the past. They saw it as a waterfall thing. In Extreme Programming explained, Ken Beck said this. "Architecture is the big boxes and connections. A system's architecture should be the result of implementing the first user stories." A good choice of "first user stories", then, would lead to a good architecture.

It can lead to an embryo, or a template, of the system's technical design. It can never lead to a business-driven and sustainable architecture. For that, you need an intentional architectural approach.

Agile software development was a reaction against waterfall approaches. The more recent Business Agility Manifesto is a reaction to agile approaches to architecture.

The first statement of this manifesto's Prime Directive's second paragraph makes a statement about this:

"Developing software faster is not sufficient, in and of itself, for survival and growth because once operational, such software is likely to prove difficult to continuously and rapidly change without unintended consequences."

The third statement of its third paragraph has this to say:

#Avoidable scrap and rework due to lack of business knowledge and lack of alignment is pure waste."

Any non-trivial project clearly needs two approaches to architecture:

• An intentional effort to establish an architecture that aligns to the corresponding business architecture.
• A foundation of business knowledge.

To achieve this, an effort to picture that business architecture is essential. If you don't do that, how could you create a software architecture that aligns to it?

It's just as important, though, not to fall in the waterfall trap. Requirement analysis as well as architectural design must be agile. If they are not, the project is dead from the start.

In the Certified Software Architect Microsoft Platform program, you'll learn how to do that. Not just in an abstract theoretical but in a practical way. You and your team should be able to take immediate advantage of this in sharp projects.

What's more, you'll learn about the Sundblad Agility Cycle:

It consists of three agile phases, each ocurring iteratively:

• The first phase is for putting your backlog into a business-driven structure. It then sends pieces of that structure, one increment at a time, to the Service and API Design phase. This is driven by business-driven priorities. Work items with the highest priorities will be the first to send.
• In the second phase, you first use these increments to prepare your backlog work items for implementation. It then delivers Service and API Design Increments and Service API Increments to the third phase. These deliveries are planned so that they fit in with the overall sprint planning.

All this is agnostic to the agile process tool you're using. It should help you set up a sustainable and intentionally business-driven architecture for your system. It should also help you convey the needed information about it to the developers who implement the sprint's user stories.

There's something more to say about this, and it might even be more important. The business-driven structure you set up for your work items will help you immensely improve your conversations about the system with business stakeholders. Read more about that in the Getting the Best From Users and Business Stakeholders highlight.