What is Architecture to me?

So for my next article in this series, there was a comment I left hanging in my last one:

"Yes there are lots and lots of flavours of this; Business, Enterprise, Security, Infrastructure, Application, Principal, Solution and a whole host of others that differ from company to company."

Which definitely needs to be explored. Officially speaking I'm a "Solution" Architect. Which can pretty much be any/all of the flavours of Architect above, like a smorgasbord of Architecture responsibility.

So what is Architecture to me and what does my day to day look like?

Solutions Architecture

So, a Solution Architect..... tends to have 1 or more Systems and is responsible for the technical ownership of them. They'll draw some system designs - "boxes and arrows" at what's often called a High Level. This box talks to this box that then talks to this box. All technical detail is abstracted away and it's the simplest view of the system possible, including internal systems and external third party ones (think salesforce, workday, etc). It'll show what the basic flow of data looks like and how that crosses across other Systems and domains.

They should (I say should as it's different everywhere and for everyone) also have supporting documentation to describe the box (or boxes) they own. I'll do another article on the story of a solution design because there's plenty to talk about "how" solutions should be described.

Those 2 documents together are key. We are responsible to make sure there's adequate documentation describing what a solution does, how it does it and why it's doing it. That way, anybody who comes along and wants to learn about it, can read the document first and learn all about it without needing to rely on an individual sharing their knowledge. It's critical to abstract a solution away from a person. People move on and leave companies, they forget things, a documented historical artefact of that solution lives forever. Systems are rarely short term, this has to be considered when writing documentation.

So a Solution Architect needs to be competent in the written word.

A Solution is also a fairly public component of a company. You might be lucky enough to design something isolated, hidden, that people don't really need to know about. If not, then you'll almost certainly need a third supporting document for your solution. The dreaded presentation. That "PowerPoint" you'll have to run through time and time again, to various members of the business, from Director level downwards. Maybe you are justifying the expense of a project, or sharing it's success. Either way, an Architect has to be able to not only create an engaging and interesting presentation but they also need to deliver that message, in a language the audience will understand. Presentation skills cannot be underestimated. For me, it's something I do weekly although I'm lucky that I like the sound of my own voice but really, it's because I'm always invested in what I'm working on and always willing to discuss it.

Then another key part of my role is the talking. There's always lots of talking. To help formulate a design;

• There's conversations with the business to understand requirements. These will take place with a Business Analyst to understand "what" is needed. It's not a technical conversation but understanding what problems we need to solve forms the foundation of the Solution. If you can't solve the business problem, you'll never "win".

• Any other Systems I might need to interact with, I'll talk with colleagues in those business/tech domains to understand how we can integrate and share the data. It could be an Architect, a Platform Lead, a Lead Engineer - whoever has that Technical ownership.

• There's going to be some sort of a Technical governance group, where the Solution needs to be presented and "approved". They'll give insight from their own experience, ask probing questions to see if I have gaps.

• If a design moves towards a Buy decision (more on that in another article) then there will be a super exciting RFP process talking to potential Suppliers and evaluating their offering. Is this fit for purpose, will it meet any NFRs, how locked in might we be with this choice etc.

• Finally, there's the company governance. The security team audits and checks. Is GDPR data protected? Have I designed a hole that could be exploited by outside malicious parties? In the past these have been Threat Modelling session reviewed by a Security Architect but each company has their own requirements for this.

At the point a design is "complete" the knowledge share is between the Engineers, Architect and Analyst. It's your classic pizza sized team. To get to that point, there will have been so many touch points for the Architect and Analyst that get abstracted away to make the Engineer's lives easier. You need to be able to talk to people and build up rapport with a whole host of different job roles and personalities. There's a huge social touchpoint graph of conversations to complete a Solution.

The Technical "Stuff"

We've got a High Level diagram but the next level down starts to become more technical. That's where you start seeing an API and a data store being added to a diagram. We still aren't at a super technical level here, we aren't talking code, contracts or specific technologies, it's still very abstract, still boxes and arrows but something looking more like a technical delivery and something relevant to Engineers.

This enables conversations around integration patterns and how we might share data upstream or downstream. If I know a third party solution is going to be used (more on that in another article) they'll get added to the picture along with their integration components so we can map out the journey of data to more detail than the HLD. The same goes for any internal systems that might need to be integrated too.

My rule of thumb, rightly or wrongly, is that anything that starts becoming specific to a technology - like an Azure function app, a SQL database or a Service Bus Technology (RabbitMQ) is too much detail for this level. As a reminder, I'm working as a Solution Architect, if you are lucky enough to be a Software/Application Architect you might find yourself being required to do that Technical component diagram and prescribe to Engineers exactly what needs to be built.

Once that's finished, it's time to engage with an Engineering team. Together with a Lead/Principal/Staff/Senior Engineer(s) the deep down technical design can take place. I'll input my Architecture diagrams, along with non functional requirements around load, volume, data size, performance etc. and together we assess the correct technical components to fulfil the requirements.

Key decisions tend to be;

• Relational Database vs Document Database
• API vs Service Bus
• What parts of the system need to scale and what limits do we need to put in place

I'll lead the design and make sure the technical diagram is completed, although it's a collaborative effort to put it together I have ownership of the artefact to add to my collection.

Now, something that's pretty important to understand here is that, yes, in isolation I "could" do the technical design myself but if I'm not building it and supporting it, I might make a technology decision that doesn't mesh with the team. It's only "fair" that they get a considerable say in what this looks like under the hood. They'll be the ones supporting it 24/7 while I swan off to the next project.

Equally, I shouldn't be an end to end detailed technical expert in all the technologies my company has adopted. I need to know enough to hold a conversation about the pros and cons of a technology, be able to assess it against NFRs but when it comes to the inner workings, it's left to the experts.

An Architect needs wide knowledge across all technologies a company works with, along with many other emerging ones to assess/recommend adoption but not the deep down detailed implementation. It means keeping an eye on the market, reading, following industry experts and trying to stay on top of things. Ultimately though, it's boxes and arrows that are key for me, where this Solution sits within the business and how's it's integrated.

The Project Team

My next comments are very specific to the way I like to work and definitely don't gel with how everybody likes to work. When it comes to Architecture you either dictate a Solution and move on, or you stay with it and follow it through to deployment.

For me, I love being part of project teams and I'm a strong advocate of Agile Architecture. I'll try my best (project capacity dependant) to attend all the agile ceremonies for a team and I've even been known to have my own Architecture stories as part of sprint deliveries. I want to be there, in the thick of it, supporting the team.

At the end of the day, alongside the Business Analyst, we are the subject matter experts for the Solution, the business value, the "why" something is being built so if we are working embedded within the team any questions or issues that arise can be resolved immediately. This also allows for any tweaks or changes to the design to be addressed as quickly as possible. I'm there to make sure the solution matches the design and that the team deliver to my vision.

Conclusion

It's getting a bit long now and the aim for all of this was to try and keep it short/snappy. Hopefully it gives you some insight into the value that an Architect brings but to summarise;

• We need to be experts in our specific business domain but knowledgeable in other areas (that classic T individual)
• We draw lots of boxes and arrows on pages, a diagram speaks a thousand words
• We need to be able to write clear, concise and engaging documentation
• We talk to A LOT of people across the business and third parties, communication is key
• We need to be able to present our Solution to all levels of a business
• There's a whole Technical knowledge and understanding that comes with it, we need to be continuous learners

To round out my list of articles - I'll cover off;

• The narrative and artefacts of a Solution
• The Build vs Buy decision

Which will hopefully give people a rounded view of the value Architecture brings to a business and what Architecture means to me.

Thanks for your time!