It means that the heart of thinking architecturally about software is to decide what is important, i. For a developer to become an architect, they need to be able to recognize what elements are important, recognizing what elements are likely to result in serious problems should they not be controlled.
Ralph's email formed the core of my column for IEEE software , which discussed the meaning of software architecture and the role of an architect. Architecture is a tricky subject for the customers and users of software products - as it isn't something they immediately perceive. But a poor architecture is a major contributor to the growth of cruft - elements of the software that impede the ability of developers to understand the software.
Software that contains a lot of cruft is much harder to modif y, leading to features that arrive more slowly and with more defects. This situation is counter to our usual experience. We are used to something that is "high quality" as something that costs more.
For some aspects of software, such as the user-experience, this can be true. But when it comes to the architecture, and other aspects of internal quality, this relationship is reversed. High internal quality leads to faster delivery of new features , because there is less cruft to get in the way.
While it is true that we can sacrifice quality for faster delivery in the short term, before the build up of cruft has an impact, people underestimate how quickly the cruft leads to an overall slower delivery. While this isn't something that can be objectively measured, experienced developers reckon that attention to internal quality pays off in weeks not months. The important decisions in software development vary with the scale of the context that we're thinking about.
A common scale is that of an application, hence "application architecture". The first problem with defining application architecture is that there's no clear definition of what an application is. My view is that applications are a social construction :.
Such a loose definition leads to many potential sizes of an application, varying from a few to a few hundred people on the development team. You'll notice I look at size as the amount of people involved, which I feel is the most useful way of measuring such things.
The key difference between this and enterprise architecture is that there is a significant degree of unified purpose around the social construction. One of the undecided problems of software development is deciding what the boundaries of a piece of software is. Is a browser part of an operating system or not? Many proponents of Service Oriented Architecture believe that applications are going away - thus future enterprise software development will be about assembling services together.
I don't think applications are going away for the same reasons why application boundaries are so hard to draw. Essentially applications are social constructions :. The microservice architectural pattern is an approach to developing a single application as a suite of small services, each running in its own process and communicating with lightweight mechanisms, often an HTTP resource API.
These services are built around business capabilities and independently deployable by fully automated deployment machinery. There is a bare minimum of centralized management of these services, which may be written in different programming languages and use different data storage technologies.
While their advantages have made them very fashionable in the last few years, they come with the costs of increasing distribution, weakened consistency and require maturity in operational management. By using these ideas, and related ones like single-page applications, such architectures remove much of the need for a traditional always-on server component.
Serverless architectures may benefit from significantly reduced operational cost, complexity, and engineering lead time, at a cost of increased reliance on vendor dependencies and comparatively immature supporting services. Good frontend development is hard. Scaling frontend development so that many teams can work simultaneously on a large and complex product is even harder. In this article we'll describe a recent trend of breaking up frontend monoliths into many smaller, more manageable pieces, and how this architecture can increase the effectiveness and efficiency of teams working on frontend code.
As well as talking about the various benefits and costs, we'll cover some of the implementation options that are available, and we'll dive deep into a full example application that demonstrates the technique.
One of the most common ways to modularize an information-rich program is to separate it into three broad layers: presentation UI , domain logic aka business logic , and data access. So you often see web applications divided into a web layer that knows about handling HTTP requests and rendering HTML, a business logic layer that contains validations and calculations, and a data access layer that sorts out how to manage persistent data in a database or remote services.
While application architecture concentrates on the architecture within some form of notional application boundary, enterprise architecture looks architecture across a large enterprise.
Such an organization is usually too large to group all its software in any kind of cohesive grouping, thus requiring coordination across teams with many codebases, that have developed in isolation from each other, with funding and users that operate independently of each other. Much of enterprise architecture is about understanding what is worth the costs of central coordination, and what form that coordination should take.
At one extreme is a central architecture group that must approve all architectural decision for every software system in the enterprise. Such groups slow down decision making and cannot truly understand the issues across such a wide portfolio of systems, leading to poor decision-making.
Continuous Delivery uses automation and collaborative workflows to remove this bottleneck, allowing teams to release software as often as the customers demand.
For Continuous Delivery to be possible, we need to build in a solid foundation of Testing , with a range of automated tests that can give us confidence that our changes haven't introduced any bugs.
This leads us to integrate testing into programming, which can act to improve our architecture. There are many kinds of software out there, the kind I'm primarily engaged is Enterprise Applications. One of the enduring problems we need to tackle in this world is data management. The aspects of data managment I've focused on here are how to migrate data stores as their applications respond to changing needs, coping with different contexts across a large enterprise, the role of NoSQL databases, and the broader issues of coping with data that is both Big and Messy.
A common problem in complex software systems is how to capture complicated domain logic in a way that programmers can both easily manipulate and also easily communicate to domain experts.
Domain-Specific Languages DSLs create a custom language for a particular problem, either with custom parsers or by conventions within a host language. I'm also the editor of a signature series for Addison-Wesley that includes five jolt award winners. I'm often asked to give talks at conferences, from which I've inferred that I'm a pretty good speaker - which is ironic since I really hate giving talks. You can form your own opinion of my talks by watching videos of some my conference talks.
I've long been a fan of board games, I enjoy a game that fully occupies my mind, clearing out all the serious thoughts for a bit, while enjoying the company of good friends. Modern board games saw dramatic improvement in the 's with the rise of Eurogames, and I expect many people would be surprised if they haven't tried any of this new generation. I also appear regularly on Heavy Cardboard.
Good technical design decisions are very dependent on context. Teams that regularly work together on common goals are able to communicate regularly and negotiate changes quickly. These teams exhibit a strong force of alignment, and can make technology and design decisions that harness that strong force.
As we zoom out in a larger organisation an increasingly weak force exists between teams and divisions that work independently and have less frequent collaboration. Recognising the differences in these strong and weak forces allows us to make better decisions and give better guidance for each level, allowing for more empowered teams that can move faster.
Within each normal-sized team, limit the choice of alternatives for any class of technology to three. These are: the current sensible default, the one we're experimenting with as a trial, and the one that we hate and want to retire.
Understanding the second order implications and unintended consequences caused by the chosen implementation is key to building an effective, secure, and scalable solution.
My colleague Carl Nygard describes how to think of these choices through a series of four patterns for handling compliance. I'm pleased to write a foreword for this book as it is solid guide to learning how to get past faux-agile and develop the skills you need to get the benefits of the agile way of work. But in the tumult of so many software projects, it can be difficult to step back and understand the implications of our work.
In the last few months my colleagues at Thoughtworks have been putting together a catalog of techniques that we can use to address this problem, which they published as the Responsible Tech Playbook.
0コメント