In their book “Building Evolutionary Architectures”, N. Ford, R. Parsons and P. Kua introduce a new way to look at software architecture where changes to requirements become part of the business as usual. These concepts were already set in motion by Agile, DevOps and CI/CD but the authors add a refreshing concept to the mix.
How are we going to measure the suitability of our architecture compared to the every changing requirements?
The proposed solution lays in measuring how far or how close the characteristic of the current architecture are from the ideal or expected characteristics. The solution was inspired by statistical models were we want to fit a curve to a set of data points by fitting a function. An expression of the suitability of the curve’s function is called the fitness of such a function.
The same concept can be applied to software architectures. Required architectural characteristics a.k.a. as the technical *-abilities can be measured by fitness functions. When the architecture changes the impact is measured by these fitness functions and as a result the changes become quantifiable and controllable.
An architectural fitness function provides an objective integrity assessment of some architectural characteristic. Combining the outcomes of the collection of fitness functions gives a view on the overall architecture.
Making architecture capable of evolving requires 3 things:
An architecture that supports incremental change
An architecture that can be measured so the changes can be guided
An architecture with the appropriate level of coupling to allow for an optimal change process
Enterprise Architecture (EA) as Strategy by Ross, Weill and Robertson was written some time ago in 2006 but still has valuable insights to offer.
The book rightfully underlines that EA is not an IT problem but a business problem to solve. Hence EA as strategy since business should be in the driving seat.
Further it explains EA is based on three components:
An Operating Model
EA Maturity Model
An IT Engagement Model
The operating models are evaluated in a two-dimensional quadrant: one axis is the level of process integration (read shared data) and the other axis is the process standardization across the enterprise. This results in four flavors of operation models:
“When it comes to getting things done, we need fewer architects and more bricklayers”. In managing the unmanageable, Mantle and Lichty, explain how to run a software development team from hiring and firing to project inception and delivery. Interesting read for every project manager.
The Imposter’s Handbook is a fun to read book. It starts from the idea that anyone without a Computer Science degree can get quickly into the most common concepts, slang and buzzwords used in the IT industry.
We all know that we use CS jargon (may-be BS jargon) to make things look more complex and to make us look smart.
The book claims to cover all the concepts of a CS degree which is a bit exaggerated but still a lot is covered. Topics are: