Solution Architecture

As a reminder, I use solution architecture (SA) as a generic term for integration and solution architectures. In fact, these days, there are not many architects that are wholly focussed on integration only. Almost always, there is a need to understand the business requirements, enterprise constraints, strategy, road map, etc. to derive an optimal integration. Invariably, these demands pull the integration architect to a level that goes beyond integration per se. I have borrowed heavily from Daljit Banger and images he has created on SA, for this release of the newsletter. This first image, by Daljit, provides a kind of system/solution overview.

Solution architecture usually covers all these layers. Although, I have seen this image, with "Integration" placed above "Data". In very large enterprises, it is sometimes the case that the presentation (customer-facing) layer, is independent/separate from the other layers. This can be due to a number of drivers; security architecture, ring/onion architecture, MACH architecture, etc. However, I recommend that all SA understand the whole picture. For an end-to-end solution, the demands of the presentation tier percolate down to every layer, including integration. This ensures that the overall solution is fit-for-use (ITIL4 Warranty). The boundaries of responsibility for the SA therefore overlaps the integration architect, and the latter is often subsumed within the former, in most enterprises.

Recall that businesses use technology to gain some kind of benefit: revenue, productivity, savings, time-to-market, innovation, brand distinction, etc. Therefore, the impetus for SA is always a business change. Not every business change will require an equivalent IT change. However, change or no-change, in the IT scope, cannot be established, without some architectural review. For this reason, your involvement as SA will have a broader scope than the Software Development Lifecycle (SDLC). Everything starts with the business. Depending on the change, there might be some qualification and refinement by enterprise architecture (EA). Then you, as the SA, gets involved, followed by technical/application/infrastructure architects, according to the kind of change.

As the SA, your empathy and connection with all arms of architecture, as well as frontline project involvement, is a great asset. You need to use it courageously to influence all of these stakeholders, to make the best choices, for the solution at hand, as well as the enterprise. If the whole is wonky, it does not matter how good the parts are, and if the parts are poor, the whole cannot make up the deficit. Solutions and enterprise strategy must align for organisational resilience and excellence, and the influence is bidirectional. You are in the centre.

Here is another diagram from Daljit.

Here, he portrays an enterprise solution architecture view. For most SA, involvement will normally start at the third stage/row. However, if you have an aspiration to grow into EA, you should show an interest, and get involved in the two earlier stages. In this illustration, the business is at the top and the solution is at the bottom. The closer you are to the top, the better your view of the business as a whole, and strategy from both business and technical perspectives. The closer you are to the bottom, the deeper your involvement in technical and operational details, as well as project specificities. It is possible to straddle all stages, but it is likely that you will lose depth of involvement and knowledge in some areas. My advice is, choose your career goals/aspirations, and try to get more engagement in the relevant stages.

While you function in the SA role, here are a few things to keep a close eye on.

Refinement of Requirements

It is important that you try and nail this down before you set out, even in an Agile context! Some folks think Agile means, take each day as it comes; that is wrong. There should be Epics and Sprints. While one can be woolly on Epics, especially future ones, you should not go into Sprints, without a clear outcome (exit metrics). As the SA, a lot of stakeholders will be looking to you on the viability of the MVP. You must be clear on what changes, IT or otherwise, are desired by your customer, and how the next steps (Sprints) take you closer to the end state. You could see this as an opportunity to practise transition states in a roadmap.

Clarification on funding

This might not always be an issue, as the delivery contract could be one of "fixed price" or "time and materials". But even if the latter is the case, as SA, you should be clear about the source and timely availability of funding. I also advise that you err on the side of caution. Better to over-provision, than to be short of funds later. It is much easier to return a surplus, than to ask for help in addressing a deficit. Over time, the former bolsters your image, folks get to understand your risk profile, and link it to your record for on-budget delivery.

Timelines and resourcing

This is often the remit of the programme management office (PMO), but there are implications for technological change. If there is an immovable deadline and/or fixed team(s), certain changes become high-risk. With such constraints, you should avoid the introduction of new technologies, patterns, frameworks, products or exploratory works - Proof of Concept (PoC). The exception being, that these have all been more than adequately factored into the timelines. The lesser evil is fixed resources. Be especially careful with fixed deadlines. You cannot easily gain speed by adding more persons/teams! I will share more details in a later release.

Principles, Standards, Patterns, Best Practise, etc.

Design traceability is an important consideration that you should seek to establish as the SA. On every project, your solution design should show how enterprise technology values, constraints and direction, are respected in a given solution. As the hub of the enterprise, your steer to projects and programmes, should be an embodiment of enterprise principles, approved patterns/products/services/partners, as well as the best practises that have been learnt by the organisation. This alignment should be reflected in your communications.

Documentation

Of course, this means that you will need to produce documents that bring all of this together. The solution design document being the primary thing. Avoid documentation as an end in itself. Make sure that you identify roles/persons that will/should consume every item you include. I strongly recommend that you maintain a RAID log, either directly, or via a proxy. This should be a separate document, as it reads like a diary, unlike the solution design per se. For the immediate present, documentation draws the lines that connect the enterprise together, in one scenario of operation/use. As time passes, it provides justification or explanation for why the solution was crafted in a certain form, at the particular time. The RAID log is especially helpful when reviewing old(er) solutions.

Implementation Governance

I have had two shocking encounters, in which I became aware that certain colleagues had not bothered to read design documents. In the first instance, it was because the chap felt that he had superior intelligence. The second was just laziness. Here is the lesson I learnt. Don't assume that design will be followed, simply because it has been communicated and explained. As SA, you should verify design traceability, either directly or through delegates. More on that when I talk about teams. Remember, if the implementation is off-mark, technical debt is incurred, making the long term cost-of-ownership higher, without any benefit for the business. You lead technology change to aid/facilitate business, therefore, you need to keep an eye on implementation.

Project History and Contacts

No one remembers everything. Indeed, as SA, you are primarily a thinker not a catalogue or diary. Save your mind for thinking, inventing and adapting solutions, not for remembering everything. But, if or when things go south, it is useful that you are able to, recollect some things, look up some things, and reach out to some folks. Things include conversations, events, emails, chat messages, and documents. Therefore, you should keep as much useful information as you can. I have sometimes found that the answer to a question lies in an email that I sent or received, months ago. Yes, I could do the research and find the answer again, but it is so much easier looking it up in that email, chat or document. However, there are other times when you just need to ask someone. To ask, you've got to know someone. To know someone, you've got to build relationships. As an SA, your network of relationships is your greatest asset. You must invest in relationships, from day one. But that is a story for another release.

That is all for now. As always, let me have feedback/comments, and I will respond, at the earliest convenience.? Until the next release, adios for now. ????????