Chapter 1
The Need for Incremental Software Architecture

Technical books rarely begin with conclusions. But the impetus for this book is so strong that it must be revealed at the onset. So, with no time to spare, here is the bottom line: IT and business organizations, in their current incarnations, must be eliminated. Replacing them with regional,1 nimble, and smaller management and technical groups, called Micro-Organizations in this book, will be of immense benefit to the product and software development community.

Mere replacement is not enough, however. Merging a Micro-IT organization with its Micro-Business organization counterpart could diminish the constant battle for alignment efforts and improve firm-wide communication. Moreover, unifying smaller business and IT groups to provide rapid enterprise solutions could reduce the long-running frictions between the two, and create a more productive work environment.

This vision accentuates the need to break down the traditional enterprise centralized management into smaller decentralized organizations to boost efficiency and speed up decision-making. Consequently, regional, small-scale, and agile Micro-Organizations would seize governance and best practices responsibilities to deliver practical and superior systems.

As a result, joint business and IT teams would operate autonomously to deliver and integrate products on time and on budget. Rather than reporting to enterprise executives, teams would report to regional management, which understands the distinct culture and requirements of local business operations.2

Such a shift in organizational thinking would eliminate the difficulties of trying to conserve a centralized management structure that is slow to respond to critical business events. A lightweight Micro-Organization would then become proactive, reducing the staggering cost of enterprise policing and governance. Enterprise-wide technology standardization, therefore, would be the practice of the past. And enterprise-wide architecture best practices and standards would cease to exist.

This does not imply that enterprise-wide architecture groups would vanish, too. The charter of such a design organization would shift to a more tangible one. For that reason, architects should focus on providing certified architecture blueprints guaranteed to work in a production environment.

As you progress through the book, keep the Micro-Organizations idea in mind. And if time allows, imagine a workplace that accepts nothing less than devoting all its precious energy to producing high-quality and practical products.

For now, let us focus on chief thrust of this book: presenting a new approach to enterprise software design, development, and integration-Incremental Software Architecture.

The new method unveiled in the chapters that follow is suited for all enterprises, regardless of their structure and organization. Pursuing the incremental software architecture approach also may drive organizations to break down their convoluted structures into agile Micro-Organizations, accelerating time to market.

In the meantime, though, there is a compelling reason to understand what incremental software architecture is, and how it can be employed to ward off the deployment of failing systems to production environments. This new approach could also be pursued to save underperforming systems and improve enterprise integration of applications, middleware, and network infrastructure.

Now, we've got our work cut out for us. Let's roll up our sleeves and move on.

End-State Enterprise Architecture: A Risky Proposition

The design phase of enterprise applications and infrastructure integration calls for the delivery of an end-state architecture. Architects, typically senior designers, submit appropriate artifacts to communicate the future state of a production environment to the business, software development, and operations groups. Specifically, the delivery includes diagrams illustrating an ecosystem in which applications and middleware run on networks, exchanging messages to execute business transactions.

Again, end-state architecture is all about future technological implementation, integration, and distribution of business services to consumers, empowered by enabling infrastructure, to ensure enterprise operation continuity and stability.

Software architects who deliver an end-state architecture diagram typically claim that the design is solid and unbreakable. In many cases, however, such an artifact merely illustrates intangible and unproven deployment that later may fail to operate in production, despite the vast knowledge and experience of its creators.

Why is this architecture unproven? A theoretical enterprise end-state architecture diagram guarantees nothing. Would a depiction of a production environment meet business and technical requirements? Would the illustrated applications operate flawlessly in production? Would service level agreements (SLAs) be fulfilled?

No one really knows.

The consequences of such a theoretical and risky design could be devastating to the business organization that is unable to launch software products on time in harsh market conditions. The skyrocketing cost of the software development efforts that follow an unproven enterprise end-state architecture could be calamitous, and the loss of revenue is typically vast.

Do Not Invest in Unproven Enterprise End-State Architecture

What then would be the consequences of launching a large-scale, or even midsize, software development and integration project enterprise-wide without knowing if in fact the end-state architecture will work in production?

Traditionally, once teams are engaged in actual software development and delivery initiatives, budgets would have been already approved. Allocated funds deplete exponentially as time goes by. Development teams devour resources at the speed of light, and cost projections are proven false. Consequently, the actual software construction, deployment, and integration phases often commit organizations to overwhelming expenditure, with little chance to reverse the course of projects-resulting in irreparable loss of resources and time.

Business and technological management should not accept an unproven end-state architecture, of which no one can predict the pitfalls of ill-designed systems and their corresponding operating environments. Budgets should not be approved and allocated to implement theoretical or academic architecture blueprints.

Simply put, do not support speculative architecture.

To prevent such mistakes, a new enterprise design process is therefore required. One that is proven and reliable. One devised to strengthen the trust between software design practitioners and business organizations. The term "proven" means that the end-state architecture should not be a theoretical proposition. It must be a software design and development model based on tangible and realistic facts, pretested, verified, and certified. This approach should guide software developers and integrators to deliver smaller chunks of solid code for one purpose only-verification of enterprise architecture assumptions.

Consequently, the software construction phase, as we know it now, would transmute into a concrete form of design proof, circumventing financial calamity that is hard to recoup.

How can such a method be accomplished?

Focus on Incremental Software Architecture

A new enterprise approach for software product construction, deployment, and integration should be considered. Chartered to deliver proven and solid architecture, design practitioners should lead source code construction and delivery initiatives. They should be accountable for the quality of their design throughout the overall product creation and distribution life cycle.

Developers, on the other hand, should take the back seat, respond to the design pace, and follow successions of software architecture progression. Indeed, they should avoid organically grown environments that are not aligned with an emerging design strategy. Developers should also seek direction from design teams, rather than employing shaky technologies that may fail to perform in production.

Incremental architecture, then, should mark a shift in the phases of enterprise software design, development, and integration.

So What Is Incremental Architecture?

Imagine an end-state architecture diagram that illustrates a production environment, in which a number of systems depend on each other, integrated to enable business transactions. In this diagram, as depicted in Figure 1.1, you may also find a number of architecture components, such as the data access layer, business services layer, repositories, gateways, adapters, and software proxies. In addition, you may note an enterprise service bus (ESB)-a mediating middleware product-that enables message exchange between consumers and services.

Figure 1.1 Typical End-State Architecture Diagram

Complex? Indeed.

Does such an end-state architecture diagram represent a feasible and a proven performing environment? Can anyone assure that such an illustration depicts an error-free software implementation deployed to production? Would the source code meet business requirements? Would performance bottlenecks be nonexistent?

Now, could the end-state architecture blueprint be proven and...