Neal Ford
Neal Ford is an Application Architect at ThoughtWorks, a global IT consultancy with an exclusive focus on end-to-end software development and delivery. Before joining ThoughtWorks, Neal was the Chief Technology Officer at The DSW Group, Ltd., a nationally recognized training and development firm. Neal has a degree in Computer Science from Georgia State University specializing in languages and compilers and a minor in mathematics specializing in statistical analysis. He is also the designer and developer of applications, instructional materials, magazine articles, video presentations, and author of the books Developing with Delphi: Object-Oriented Techniques (Prentice-Hall, 1996), JBuilder 3 Unleashed (Sams, 1999) (as the lead author), Art of Java Web Development (Manning, 2003), and No Fluff, Just Stuff Anthology: The 2006 Edition (editor and contributor). His language proficiencies include Java, C#/.NET, Ruby, Object Pascal, C++, and C. His primary consulting focus is the design and construction of large-scale enterprise applications. Neal has taught on-site classes nationally and internationally to all phases of the military and to many Fortune 500 companies. He is also an internationally acclaimed speaker, having spoken at numerous developer conferences worldwide.If you have an insatiable curiosity about Neal, visit his web site at nealford.com. He welcomes feedback and can be reached at nford@thoughtworks.com.
Contrasting architecture patterns with design patterns
How both kinds of patterns can add clarity and understanding to your project.
Developers are accustomed to design patterns, as popularized in the book Design Patterns by Gamma, et al. Each pattern describes a common problem posed in object-oriented software development along with a solution, visualized via class diagrams. In the Software Architecture Fundamentals workshop, Mark Richards & I discuss a variety of architecture patterns, such as Layered, Micro-Kernel, SOA, etc. However, architecture patterns differ from design patterns in several important ways.
Components rather than classes
Architectural elements tend towards collections of classes or modules, generally represented as boxes. Diagrams about architecture represent the loftiest level looking down, whereas class diagrams are at the most atomic level. The purpose of architecture patterns is to understand how the major parts of the system fit together, how messages and data flow through the system, and other structural concerns.
Architecture diagrams tend to be less rigidly defined than class diagrams. For example, many times the purpose of the diagram is to show one aspect of the system, and simple iconography works best. For example, one aspect of the Layered architecture pattern is whether the layers are closed (only accessible from the superior layer) or open (allowed to bypass the layer if no value added), as shown in Figure 1.
Figure 1: Layered architecture with mixed closed and open layers
This feature of the architecture isn’t the most important part, but is important to call out because if affects the efficacy of this pattern. For example, if developers violate this principle (e.g., performing queries from the presentation layer directly to the data layer), it compromises the separation of concerns and layer isolation that are the prime benefits of this pattern. Often an architectural pattern consists of several diagrams, each showing an important dimension.
4 reasons why microservices resonate
Microservices optimize evolutionary change at a granular level.
We just finished the first O’Reilly Software Architecture Conference and the overwhelming most popular topic was microservices. Why all the hype about an architectural style?
Microservices are the first post-DevOps revolution architecture.
The DevOps revolution highlighted how much inadvertent friction an outdated operations mindset can cause, starting the move towards automating away manual tasks. By automating chores like machine provisioning and deployments, it suddenly became cheap to make changes that used to be expensive. Some architects properly viewed this new capability as a super power, and built architectures that fully embraced the operational aspects of their design. The Microservice architectural style prioritizes operational concerns as one of the key aspects of the architecture.
Microservice architectures borrow a design aesthetic from Domain Driven Design called the Bounded Context. A bounded context encapsulates all internal details of that domain and has explicit integration points with other bounded contexts. Microservice architectures reify the logical DDD bounded context into physical architecture. For example, it is common in microservice architectures for services that must persist data to own their database: members of the service team handle provisioning, backups, schema, migration, etc. In other words, in microservice architectures, the bounded context is also a physical context. But that also means that this service implementation isn’t coupled to any other team’s implementation, clearing the path for independent evolution. I recently published some writing about the recent realization that architecture is abstract until operationalized. In other words, until you have deployed an architecture and upgraded parts of it, you don’t fully understand it.
How CI removes the pain
The tradeoffs of (accidentally) discarding continuous integration.
I’ve given a continuous delivery workshop a few times with ThoughtWorks Chief Scientist Martin Fowler, who tells an interesting story about continuous integration, from the first software project he ever saw. When Martin was a teenager, his father had a friend who was running a software project, and he gave Martin the nickel (or five pence) tour — a bunch of men, predominately on mainframe terminals, working in an old warehouse. Martin remarked that the thing that struck him the most was when the guide told him that all the developers were “currently integrating all their code.” They had finished coding six months prior, yet despite that they weren’t sure when they were going to be done “integrating.”
That revelation surprised Martin: in his mind, software development was a discreet, scientific, deterministic process, not at all represented by the vague comments of these developers. But the practice of as-late-as-possible integration was common back in an earlier era of software development. If you look at software engineering texts of the ’60s and ’70s, every project included an integration phase. This isn’t how we think of integration today, which happens at the granularity of services and applications. Rather, a common practice was to have developers code in isolation for weeks and months at a time, then integrate all their code together into a cohesive whole. And that phase was, not surprisingly, a painful part of most projects. Yet, that type of 60s and 70s workflow is still codified in some version control tools today, even though we have now determined that late integration is the opposite of how we should approach this problem.
Elvis has left the ivory tower
Pragmatism now rules in team structure, technology, engineering practices, and operational innovation.
Ancient history in computer science (2004) provides a gem about the personas that Microsoft envisioned as users of the development environment Visual Studio. They developed three:
- Mort, the opportunistic developer, likes to create quick-working solutions for immediate problems. He focuses on productivity and learns as needed.
- Elvis, the pragmatic programmer, likes to create long-lasting solutions addressing the problem domain, and learning while working on the solution.
- Einstein, the paranoid programmer, likes to create the most efficient solution to a given problem and typically learns in advance before working on the solution.
These designations received a lot of negative press, particularly around the Mort persona, but I want to focus on Einstein and Elvis.
Formerly, software architects exemplified the Einstein persona: isolated from day-to-day development details, focused on building abstractions and frameworks. The isolation is so common that it spawned its own “Ivory Tower Architect” derogatory phrase. But the realities of building systems that scale as fast as the business does invalidates that approach. Now, Elvis, the pragmatic developer, has ascended to architect while simultaneously descending from the Ivory Tower. Modern architects don’t have the luxury of isolation from the gritty realities of software development today. Pragmatism now rules in team structure, technology, engineering practices, and operational innovation because: