Architecture and Design are terms often not heard enough within project teams – :( . It almost feels like these words where left behinds in the Computer Science universities. Two interesting books on the topic are:
What follows is a brief overview of the first book. Another blog posting will cover the 2nd book. Net out, I feel the Software Architecture in Practice book could have done more to embrace agile, and the concept of “done”
Book: Software Architecture in Practice
Page 4 start with a relevant definition:
The software architecture of a system is the set of structures needed to reason about the system, which comprise software elements, relations among them, and properties of both.
Architecture structures can be divided into three categories: Modules, Component-and-Connector (C&C), Allocation Structures. (Page 10)
Reason for why architecture are important are offered on page 25.
Business Goals drive Quality Attributes and Architecture (page 50) leads to an interesting read on page 68 on the topic of specifying quality attributes in a common form. In many ways this sounds like an opportunity for BDD, or at least the way to describe the architecture behaviour in Cucumber format to avoid the dreaded parse-translate issues that normally happens with requirements documents.
Anyone working in fiancé should be familiar with the system availability table on page 81. Planning For Failure, page 82 reminds me of the Let It Die ………..
Defect Faults, page 87, offer the usual suspects, heartbeats, voting, monitoring.
Interoperability, Modifiability and Performance (Chapters 6-8) offer good reading. Chapter 9, Security, is often overlooked, or thought about to late in the architecture. Security requirements will often influence the architecture of an application in ways not anticipated at the start of a project. One thing that is missing from “Further Reading”, page 157, is the Oracle Security Coding standards, given that a large majority of code these days in financial corporations is written in Java. Further, I would also say Data Model security should also take account of any legal implications of where the data is allowed to be located.
Testability, chapter 10, states that for a well engineered system, “30-50% (or in some cases more)” of the cost goes into testing – page 374 offer a view of 30-90% of the development budget. Thankfully, page 16 offers details of NetiFlix’s monkeys. However, chapter 10 doesn’t offer a view on leveraging the behaviour of the application as a source of truth for testing – BDD again. Opportunity lost. Page 170 does however offer some good insight into test data – which is often overlooked due to the complexity/pain of getting test data. Page 171 also calls out automated testing – large systems can’t/shouldn’t be tested manually.
Architectural Tactics and Patterns (chapter 13) offers a catalog of usual suspects – MVC, Pipe-and-Filter, Client-Server, Peer-to-Peer, SOA, Pub-Sub.
Architecture in Agile Projects (chapter 15) offers an interesting read, which a set of six principles, Incremental Commitment Model.
Chapter 16, Architecturally Significant Requirements (ASR) are possibly the closest thing to BDD. Documenting Behaviour, page 351, again unfortunately missed the opportunity to mention BDD.
Moving from Architecture to implementation is always interesting (page 363). How do you validate that the implementation is what was architected? Frameworks and code templates are obvious contenders. UML is the de facto architecture description language, but as discussed on page 369, there is still a gap between architecture and implementation.
Again, 19.2 (page 370) missed the opportunity to discuss BDD. Further, if the architected application is to deliver a certain set of behaviours, then maybe the developers and testers should work from the same set of behaviour to ensure the application is tested appropriately.
Architecture Tradeoff Analysis Method (ATAM) (page 400) offers an interesting read, which proposed agenda and architecture presentation. There is also a Lightweight Architecture Evaluation (page 415) that offers a reduction in time from 20-30 person-days to a single day – see agenda on page 416.
Competencies of Software Architecture comes in many forms. Page 468 offers a dew duties that an organisation can perform to aid successful architecture. My personal view is that architects need to still understand “code” else, we end up in world where architects are not respected by the implementation team.
Although a bit last month, Matt Turck offers an interesting read on the Bloomberg Terminal. A number of software packages are called out throughout the article, coupled with this possible key quote:
A data producer like [PsychSignal] publishes its social media sentiment index on [Quandl]. A user exports that data from Quandl to a high-end visualization service like [Plotly] or [DataHero]; extracts subtle insights using an analytics tool like [BigML]; backtests an investment strategy using [Quantopian], and then actually trades on that data using Quantopian again.
Interesting items mentioned:
- SumZero – Buy side hedge fund community
- Quantopian – Platform to allow quants share strategies and algos
- ThinkNum – Collaborate on investment research with users from around the world.
- Quandl – financial search engine
- Domino – Easily run R, Python, and Matlab code in the cloud. Automatic version control and collaboration for data, code, and results.
Coupled of interesting posting on Docker usage
- Dockerfile Tutorial | Running Apache http server inside docker container
- Docker commandline Tutorial | Running Apache http server inside docker container
- Docker is the best fit for continuous delivery
“You can create container for each component of your technology stack and they can be used on developer machine as well as production environment.”
Interesting read over on Segments.io regards Server-Sent events. Main take away appears to be that if you don’t need full 2 way communications aka WebSockets, then Server-Sent events maybe the way to go. Anyone used Server-Sent events for a web trading application?
FT has an interesting article on Big Data. The closing paragraph summaries the article well:
“Big data” has arrived, but big insights have not. The challenge now is to solve new problems and gain new answers – without making the same old statistical mistakes on a grander scale than ever.
I’ve been waiting for a blog entry to appear for Mike Cohn’s recent monthly news article, “Paying the Cost for More Precise Estimates”. Unfortunately, apart from the campaign URL, nothing has appears on Mike’s blog as far as I can see. So without waiting any long, let me offer the summary view of an excellent article – estimation is not free! I realise this maybe obvious to some, but few manager understand the “cost” associated with estimation.
To add precision to an estimate requires time
As long as a boss is willing to pay that cost, a good team should be willing to provide an estimate at whatever level of detail and precision the boss wants. The problem is when the boss wants a highly precise estimate and isn’t willing to pay the cost, for example, “I need to know by lunch time today exactly when this large project can be delivered.”
Information has a cost. If the person asking for that information is willing to pay that cost, you need to be willing to provide the information.