Architecture

Architecture is not so much about the software, but about the people who write the software. The core principles of architecture, such as coupling and cohesion, aren't about the code. The code doesn't 'care' about how cohesive or decoupled it is; … But people do care about their coupling to other team members.

Bad software architecture is a people problem.

Architectural decisions are design decisions that are hard to make or costly to change.

Architecture is just a collective hunch, a shared hallucination, an assertion by a set of stakeholders on the nature of their observable world, be it a world that is or a world as they wish it to be.

The architect's role is changing from being primarily a decision maker to being a coordinator, advisor, and knowledge manager. … a central knowledge hub.

I think that one of an architect's most important tasks is to remove architecture by finding ways to eliminate irreversibility in software designs.

There is broad consensus that architects should code.

Simple architectures have conceptual integrity and are better than more complex ones. Continuous architectural refactoring helps to converge a system to its practical and optimal simplicity.

Architecting a software-intensive system encompasses technical elements, social considerations, and a technical core. Most interesting systems start small and focus on technical concerns, but once they grow to the point of economic significance, social issues begin to loom large.

To some, the phrase 'agile architecture' is an oxymoron.

An architectural review serves several purposes: to gain confidence in the design, to reason about alternatives, to attend to architectural rot. The process of such a review involves the interplay of design decisions, scenarios, and forces on the system.

Providing architecture as a service to application developers is an effective way to implement the architecture process especially, but not only, in the context of agile development. In their role as stakeholders of nonfunctional system qualities, architects prepare and support developers by participating in coding activities and play a key role in communicating the architecture throughout the project's lifetime.

Leadership is the key for architects to balance all their activities and duties with the interests of different stakeholders without losing control of the architecture under development. They must have a clear vision and strict focus on key aspects of success. All their activities should be goal-driven and in direct cooperation and interaction with the relevant stakeholder groups.

Anticipation should be a large part of your job as an architect… If you communicate your anticipation as an evolution viewpoint or architecture roadmap, your architecture description will stay valid longer. And, you'll have a ready answer when stakeholders ask how you've addressed their change and planning concerns.

Internet scale, the increasing rate of technology evolution, and the broad adoption of lean and agile methods have triggered a profound change in not only application and infrastructure architectures but also the software architect's roles and responsibilities.

The popularity of agile methods such as Scrum and Kanban, with their clear focus on team collaboration, threatens many roles traditionally assigned to individual experts. Some organizations are even challenging the raison d'être of the software architect role. …

Two reasons why successful projects still often assign architecture-related responsibilities to individual experts acting as software architects. First,** the experts** help effectively manage complexity; second, they act as knowledge multipliers when development must scale up.

Software architects don't just design architecture components or champion architecture qualities; they often must guide and harmonize the entire community of project stakeholders. The community-shepherding aspects of the architect's role have been gaining attention, given the increasing importance of complex 'organizational rewiring' scenarios such as DevOps, open source strategies, transitions to agile development, and corporate acquisitions

As software systems have evolved, so has software architecture, with practices growing to meet each era's new challenges. The next phase of evolution--intelligent connected systems--promises to be an exciting time for software architects.

The software architecture pendulum is swinging away from traditional practices and toward agile and continuous practices. To be successful in this new world, architects should emphasize products over projects, drive architectural decisions, understand code, and communicate and collaborate effectively with delivery teams.

A well-known adage is 'diversity brings innovation.' Diversity can be in culture, thinking, discipline, gender, and many more aspects. The result is the same: the chances for creating innovation in a given context increase when diversity is involved. To some extent, this principle should also hold for gender diversity in software teams. Achieving gender diversity in IT-related fields has been a goal for decades, but still, too few women choose such a career. But what skills or traits assigned to the feminine role bring concrete advantages to software teams?

Following certain best practices for visual communication can help bridge the gap between IT architects and business stakeholders. These practices stem from disciplines such as psychology, graphic design, communication science, and cartooning.

Agile teams strive to balance short-term feature development with longer-term quality concerns. These evolutionary approaches often hit a 'complexity wall'' from the cumulative effects of unplanned changes, resulting in unreliable, poorly performing software.

An architecture haiku aims to capture software system architecture's most important details on a single piece of paper. An architecture haiku helps development teams focus on the most essential information relevant to the architecture, provides clear guidance for construction, and encourages collaboration.

Smart manufacturing networks describe a production chain as a marketplace that delivers products on demand. In this chain, partners collaborate in product work routings that connect dispersed service-enabled systems with resources, materials, human expertise, and operation-equipment combinations.

A refactoring aims to improve a certain quality while preserving others. For example, code refactoring restructures code to make it more maintainable without changing its observable behavior.

Many types of architects work in the software industry, but when we consider the breadth of their work and their primary expertise, we find that they can be organized into three major groups: enterprise architects, application architects, and infrastructure architects. Knowing which group an architect falls into helps in understanding their expertise and what to expect of them.

The Healthcare.gov debacle of 2013 leads many to wonder if a better understanding of the project's requirements could have lessened the impact of the failed launch.

Mobile cloud computing infrastructures supporting the vision of the Internet of Things (IoT) provide services beneficial to our society. For example, a cloud of smartphones can run software that shares the sensing and computing resources of nearby devices, providing increased situational awareness in a disaster zone.

Software architecture is the foundation of software system development, encompassing a system's architects' and stakeholders' strategic decisions.

Software architects must sustain design decisions to endure throughout software evolution. Several criteria can help them assess decisions' sustainability … Strategic … Measurable and Manageable … Achievable and Realistic … Rooted in Requirements … Timeless …

It's difficult to express a software architecture's sustainability in a single metric: relevant information is spread across requirements, architecture design documents, technology choices, source code, system context, and software architects' implicit knowledge. Many aspects influence economic sustainability, including design decisions facilitating evolutionary changes, adherence to good modularization practices, and technology choices.

Quality concerns, often referred to as nonfunctional requirements, service-level agreements, quality attributes, *performance constraints*, or *architecturally significant requirements*, describe system-level attributes such as *security*, *performance*, *reliability*, and *maintainability*. In conjunction with functional requirements, these quality concerns drive and constrain a *system's architectural design* and often introduce significant trade-offs that must be carefully considered and balanced. The dependencies that exist between requirements and architecture have been referred to as the twin peaks of requirements and architecture.

In the past decade, researchers have devised many methods to support and codify architecture design. However, what hampers such methods' adoption is that these methods employ abstract concepts such as views, tactics, and patterns, whereas practicing software architects choose technical design primitives from the services offered in commercial frameworks. … systematically links both top-down concepts, such as patterns and tactics, and implementation artifacts, such as frameworks, which are bottom-up concepts.

Software architects often must work with incomplete or ill-specified non-functional requirements (NFRs) and use them to make decisions. Through this process, existing NFRs are refined or modified and new ones emerge. … The survey revealed that architects usually elicit NFRs themselves in an iterative process; they usually don't document the NFRs and only partially validate them.

Lean practices use the principle of Little's law to improve the flow of value to the end user by eliminating sources of waste from a software development process. Little's law defines throughput as a ratio of work in process and cycle time. Increasing throughput (or productivity) requires continuously improving (that is, decreasing) cycle time while ensuring that the work-in-process limit doesn't exceed the capacity available to process the work.

Service-oriented architecture (SOA) has gained significant attention as a means of developing flexible and modular systems. .. not all stated benefits are realised due to, among other things, a failure of service-oriented thinking at an organisational level, problems allocating financial responsibility for services within and between organisations, and a lack of mature tool chains.

The large-scale, dynamic, and heterogeneous nature of cloud computing poses numerous security challenges. But the cloud's main challenge is to provide a robust authorization mechanism that incorporates multitenancy and virtualization aspects of resources.

If you give a hurricane meteorologist a giant pile of data about a storm spinning in the middle of the Atlantic Ocean and ask her to determine exactly where it will come ashore, she can analyze the data, construct a detailed and accurate model of the atmospheric conditions and weather patterns, run some simulations, and come up with a forecast—two months after the storm hits. It'll probably be wrong, but not by much, a moot point for the people in the storm's path. The problem isn't with the forecast's accuracy but with the time needed to prepare it. On the other extreme, if given a satellite image and a few points of other data—and a few minutes—a hurricane meteorologist can prepare a forecast so uncertain it might as well not even exist. There is a point where forecast accuracy and timeliness overlap. The model favored by hurricane meteorologists is to do just enough data acquisition and analysis to be reasonably certain what the storm will do and then start telling people to get ready.

There is complexity, and then there is organized complexity. Pure complexity is chaotic; organized complexity is full of patterns. Naming these patterns and respecting their intention is the essence of architecture.

It has long been recognized that one of the key benefits of architecting our systems is managing their complexity. This complexity arises from many factors: the needs and constraints of the multitude of system stakeholders … the political, social, and other factors from the environment in which the system is embedded; the realities and constraints of the system's development, implementation, maintenance, and operation in relation to available resources; and, of course, the intended properties of the system itself. Taken together, these diverse interests are a system's stakeholder concerns.

Architecture evaluations offer many benefits, including the early detection of problems and a better understanding of a system's possibilities. … the lightweight sanity check for implemented architectures (LiSCIA) evaluation method … can be used out of the box to perform a first architectural evaluation of a system. … By periodically performing this check, developers and project managers can control the implemented architecture's erosion as the system (and its requirements) evolves over time.

What are the top five properties that make a software design elegant? … we explore … five properties leading architects have found useful: economy, visibility, spacing, symmetry, and emergence.

Agile development delivers value quickly, using a series of short-term goals based on immediate priorities. Architecture grows value carefully, using a set of long-term objectives based on fundamental principles. The two seem at odds, but the architect can bring them together at four well-defined points in agile projects: during project initiation by setting architectural direction, through storyboarding by introducing specific architectural tasks, within sprints by close collaboration on challenging issues, and as working software gets delivered by performing direct inspection.

Enterprise architecture and technical architecture are related yet different: whereas EA focuses on the architecture of a business that uses software-intensive systems, TA focuses on the architecture of the software-intensive systems that are used by a business to makes its mission manifest.

A decision view provides a useful complement to the traditional sets of architectural views and viewpoints. It gives an explanatory perspective that illuminates the reasoning process itself and not solely its results. The decision view documents aspects of the architecture that are hard to reverse-engineer from the software itself and that are often left tacit.

Without refactoring, complex software-intensive systems become increasingly irregular and thus increasingly chaotic over time. We can understand complex software systems only when they're nearly decomposable and hierarchic. One measure … is lines of source code: the greater the SLOC, the more inertia to change the system will have, the more people it will take to keep it fed, the more stakeholders who will be crawling all over it. … the more complex measures … are tuned to Philippe Kruchten's 4+1 view model of architecture.

What is the optimal design for a given system, a design that reasonably balances all the forces that weigh in on the problem? In turn, what is the optimal organizational structure for developing, deploying, and evolving that system? The challenge for every organization is to find the sweet spot that provides the right balance of innovation, predictability, repeatability, and risk confrontation for that project at every given moment.

The architect, either as an individual, a role, or a team, lovingly crafts, grows, and governs that architecture as it emerges from the thousands of individual design decisions of which it's composed. In this sense, an architecture-first approach appears to be a reflection of sound development practices.

Virtually all well-structured music, music that pleases the ear and moves the spirit, is full of patterns. By comparing musical and software patterns, the author helps clarify the purposes and forms of patterns. Architectural and design patterns make software-intensive systems easier to understand and adapt to because of their regularity and simplicity.

All of software design involves developers making decisions and reifying those decisions in code. … However, architects often fail to document their decisions well. This leads to architectural erosion: decisions made during later development might conflict with the original architectural decisions and thus cause significant system disruptions.

The architecture of a software-intensive system is largely irrelevant to its end users. Far more important to these stakeholders is the system's behavior, exhibited by raw, working source code. As long as a system provides the right answers at the right time with all the right other '-ilities' (maintainability, dependability, changeability, and so on), end users couldn't care less about what's behind the curtain making things work. To stakeholders other than end users, however, a system's architecture is intensely interesting. Moreover, software architecture has had a hand in better project management, greater use of iterative development, and leverage from the Web's infrastructure.

Every interesting software-intensive system has an architecture. While some of these architectures are intentional, most appear to be accidental. Philippe Kruchten has observed that 'the life of a software architect is a long and rapid succession of suboptimal design decisions taken partly in the dark.'

The service-oriented paradigm is founded on an assumption of well-specified and well-understood contracts that isn't realized in practice.

By studying … architectural patterns and thus exposing … systems' inner beauty, I hope to inspire developers who want to build on the experience of other well-engineered systems.

It's been 10 years since David Garlan and Mary Shaw wrote their seminal book Software Architecture Perspective on an Emerging Discipline, since Maarten Boasson edited a special issue of IEEE Software on software architecture, and since the first International Software Architecture Workshop took place. What has happened over these 10 years? What have we learned? Where do we look for information? What's the community around this discipline? And where are we going from here?

In the near future, software architecture will attain the status of all truly successful technologies: It will be taken for granted.

UML has been around since 1997. … UML is used rather loosely and that UML models are often incomplete. This leads to miscommunication and other implementation and maintenance problems.

Including architecture-centric design and analysis methods in the Extreme Programming framework can help software developers address quality attributes in an explicit, methodical, engineering-principled way.

… SOA represents a paradigm consisting of a set of architectural principles for building loosely coupled software systems. Actually, the SOA paradigm applies not only to XML Web services but also to other technologies such as email clients and servers and message-oriented middleware.

Because we must balance the enterprise architect's goals with the needs of the agile development organization and the users driving the application's development, it helps to have enterprise architects join the development team. This provides opportunities to address the needs of all stakeholders: architects, developers, and business users.

Explicitly documenting major architecture decisions makes the architecture development process more structured and transparent. Additionally, it clarifies the architects' rationale for stakeholders, designers, and other architects.

[E]lements such as principles, heuristics, best practices, 'bad smells,' and refactorings are not clearly defined. Many of these elements are synonymous, and others are just vague concepts.

Architecture reviews … identify project problems before they become costly to fix and provide timely information to upper management so that they can make better-informed decisions.

We can divide software systems architecturally along two broad dimensions. The first is the *tarchitecture* or 'technical architecture' and the second is the *marketecture* or 'marketing architecture.' I refer to the traditional software architect or chief technologist as the tarchitect and the product-marketing manager, business manager, or program manager responsible for the system as the marketect.

Geographically distributed development teams face extraordinary communication and coordination problems. … common but unanticipated events can stretch project communication to the breaking point. Project schedules can fall apart, particularly during integration.

Objects, patterns, and architectures have much in common. Each holds the promise of solving chronic software development problems: high development costs, even higher maintenance costs, low levels of reuse, unbelievable—and unrealized—schedules, and so on.

Patterns have given us a vocabulary to talk about structures larger than modules, procedures, or objects—structures that outstrip the vocabularies of the proven object design methods that have served us for the past decade.

In the software development context, a pattern is an important and recurring system construct and a pattern language is a system of patterns organized in a structure that guides the patterns' application.

There is undoubtedly a large measure of art involved in software design. But artistic expression in the absence of rules results in chaotic design. To produce open systems, we must agree on some well-defined rules to govern interaction among systems and subsystems.

Most of the designs appeal to multiple styles, but they generally fall into four main groups: object-oriented architectures, including information hiding; state-based architectures; feedback-control architectures; and architectures that emphasize the system's real-time properties.

The 4+1 View Model describes software architecture using five concurrent views … : The logical view describes the design's object model, the process view describes the design's concurrency and synchronization aspects; the physical view describes the mapping of the software onto the hardware and shows the system's distributed aspects, and the development view describes the software's static organization in the development environment. Software designers can organize the description of their architectural decisions around these four views and then illustrate them with a few selected use cases, or scenarios, which constitute a fifth view.

The software factory concept … symbolizes a desired paradigm shift from labor-intensive software production to a more capital-intensive style in which substantial investments can be made at an acceptable risk level …