Software Architecture, all you need to know [pdf]

I work in the public sector of Denmark, we’ve spent the past 15 years trying to get some cross-sectoral standards up and running. We’re getting there on data services as well as authentication and indexes of data, and that means we’re starting to build systems that work together everywhere.

Very few actual technologies have been dictated in this process. We have architectural standards for how data should be handled and how information flows are supposed to function, but no one dictates what technologies you use to build or deploy your system.

We do have some, like I said, like a national standard for how we authenticate users and handle their rights using something called OIOtokens. They work with standard federated services though, so you can use key-cloak if you’re into Linux or ADFS if you’re into Windows (95% of the public sector) or something else that does federated SAML authentication.

Our dataservices similarly aren’t dictated to use X, simply instructed in how information is supposed to transfer. So you can use SOAP, REST, GraphQL or whatever floats your boat, as long as the information fits the national architecture standards.

You couldn’t do any of this without centralisation. On a lower level, most suppliers adopt the national standards into their own, and then add to them within their own companies or organisations, but that works perfectly fine, because everyone knows the patterns for sharing data and information.

I would say that a good architect, and a good development process, certainly involve collaboration between numerous stakeholders. The solution architect, tech leads, product owners, QA, etc., all have a voice and should all be talking to each other quite a lot.

That said, it's good to have somebody who owns the overall vision of the technical architecture, and can be a tie-breaking vote, or exercise veto authority over things when needed.

All in all, I believe the main job of the solution architect is to define, and defend, the "skeleton" of the solution, and then let everybody else hang their respective pieces off of that skeleton. Done right, the skeleton should be just prescriptive enough that any "component" attached to it will work smoothly with the others.

I have seen this only when working in European companies. For some reason, these roles exist which is not bad in it self. However the majority of the architects I encountered are completely hands-off on the development part which causes lot of problems like teams that are not empowered to move fast and ridiculously complex architectures in MVP stages of products.

No, I do not think so. The software (but not the solution/enterprise) architect is a technology expert. For a solution architect it is less important to know all details of a technology but more about understanding the technology landscape. Software Architects are best embedded with the teams (basically your tech leads) but Solution Architects have to consider things which are beyond the understanding of the team (and then carry that into the teams).

In my own experience as an architect, it is the other way around. I can invest in new technology knowledge while we keep our dev teams at 100% workload. When they idle the company practically loose money and cannot deliver to the market (and I know that this is stupid for an individual). This usually results in a situation, that if a team comes with a tech solution, the architect team already has a good rationale about it.

You're right! Having a council of tech leads is absolutely a viable approach to designing overall architecture.

With that said, it seems to me that each tech lead might individually suffer the same problem you have wisely identified - architects failing to keep up. As a result, it's perhaps possible that you might wind up with a committee of tech leads that have useful expertise in their domain but minimal knowledge outside of it.

My experience with design-by-committee is that it can be challenging to get a quality design out of one when members have broadly shared expertise, backgrounds, and interests. It's very possible that putting a bunch of people with different expertise and interests in a group and asking them to design something might get you a far superior design! It may be worth considering that it could also produce one with one with opportunity to adopt a unified vision.

My experiences to date have been that you're absolutely correct - a council of tech leads is unquestionably invaluable for their ability to supply critical technical detail to an architectural project. It just may be worth considering having an owner for the architecture itself, rather than having it be subject to the vicissitude of community ownership..

I think this is an internal paper addressing other contributors, explaining the architecture roles, core techniques, etc specific to this company. This is not a 101 in architecture.

It is not a full

I don't know if it's one of the best, but I really enjoyed "Design It!" from pragprog. I liked that it's focused on pratices that can be applied to my job while giving plenty of pointers to theoretical topics to explore more in depth. I guess it's a very beginner book though.

I’ve enjoyed the depth of thought found in—and triggered by—John Ousterhout’s A Philosophy of Software Design. It packs a lot into an easy-to-read, directly to-the-point format.

There is no royal road to [architecture], software or bricks. It is a serious field of creative and intellectual inquiry that requires exploration, experimentation, and verification.

Solution architecture may incorporate non-software related concepts and processes, thus defining the role of solution architect broader than role of software architect and requiring bigger set of skills (e.g. when some process should be implemented without software via manual labor, you‘ll need certain understanding of human psychology to evaluate its efficiency). As a solution architect you solve a business problem, using software as necessary. As software architect you focus only on those business problems, which require software. That’s the difference, as it should be (but quite often it’s just one or another marketing tag, as you correctly suggest).