It is truly amazing that it has been over 5 years since my last blog post. In that time, architecture, application development and integration has changed immensely.
Service-based integration has gone through this transition:
- ESB-centric SOAP-based SOA has died, reimagined with a focus on beautiful RESTful APIs implemented that microservices that finally realise the principle of service autonomy.
- With the rise of mobile, B2B gateways gave way (through evolution or revolution) to APIs gateways – which started out light but are starting to smell like ESBs, so ..
- in the spirit of smart endpoints and dumb pipes, the next big thing is the service mesh – so that’s where my blogging journey will probably begin. To whet your appetite, check out this really interesting talk on Istio and Envoy, which included a passing reference to a project that I find particularly interesting .. Open Policy Agent.
In the constant quest to build more resilient systems, reactive architectures have led us away from the mindset where we rely on strong consistency and synchronous request reply interaction. There is a resurgence in the use of messaging as a pattern, and ideas that were previously considered heresy such as eventual consistency (“it’ll be right” is ok for the enterprise!) and event sourcing to build domain-specific views of reality are mainstream.
Data integration has shifted gears even more, moving from batch-oriented ETL to real-time data streaming. Just to make it more confusing, we see the convergence between data streaming and messaging in platforms like Kafka and Amazon Kinesis. Is it a message broker? An event store? Why not both?
finally .. the cloud is no longer just a playpen for startups – it is mainstream in the enterprise and has moved infrastructure into the hands of the developer – which means that in addition to knowing how to build apps in their chosen functional or technical domain, developers, engineers, architects have a whole new domain to learn.
oh, and let’s not forget containers .. and AI .. machine learning .. virtual assistants …
Anyway, this is just a finger-stretching exercise to check that there’s still a blogger in the house. The next instalment will a) hopefully not be in 5 years and b) dive a little deeper into one of the above topics.
Until next time …
Have you ever been in a meeting where you ask ‘how’ something works and you only get an answer about what it does? Or .. you get an answer that is so detailed that you make a mental note never to invite the respondent to the meeting because they are “too low level”. Or .. you ask why a component works a certain way and the answer is ‘ask the architect’ (hmm .. I thought you were the architect?)
It almost seems that you get a different answer depending on WHO you ask – even within the same team! This is particularly bad in the IT architecture space because – well – everyone wants to be an architect. I personally remember the feeling of absolute glee when after approx 5 years of waiting and 2 job changes, I officially landed a role where I was ‘the architect’. You would not believe what sort of other titles people will come up with just to avoid calling you an architect (at least that’s what it felt like at the time!).
Ok – back to the point of the post. I thought it might be an idea to try and express the different types of architect roles (WHO) in your typical big-IT environment and how their work interrelates in a complex web of why,what and how. If nothing else, it’ll help me remember who what sort of answer to expect when I ask the business architect ‘how’ a given component we are building affects the business user..
- The business architect helps the business to define a suitable business process to achieve a given outcome (BUSINESS WHY) and out of this, what technology needs to do in order to support the business. At this stage, all we have is a ‘BUSINESS HOW’ that may have some technology components.
- If a process involves technology, the solution architect is given the business process definition and any related material as input/justification (the SOLUTION WHY) and asked to come up with a solution. They start from the technology touchpoints identified in the BUSINESS HOW, and in conjunction with the business architect and/or business analysts gathers further details around how the business process will really interact with technology to achieve this outcome. At this stage, we have progressed our understanding to a ‘SOLUTION WHAT’ (ie what is the solution really meant to do, precisely defined in reasonably measurable tech-friendly terms).
- next the solution architect works with various specialists (ok, “technical architects”) to devise a workable end to end solution to meet the objective. At this stage they have defined a ‘SOLUTION HOW’ at minimum, and if they have really taken the time to talk to the people responsible for all the components, they may also have specified what each components is responsible for – i.e. ‘COMPONENT WHAT’s. Interaction definitions within the solution design provide justification these capabilities, so the solution design also serves the role of the ‘COMPONENT WHY’.
- finally in order to actually build out the components, the specialists need to work out ‘HOW’ they are going to make their component do what the solution architect has come up with. This gets captured in detailed specs which are the ‘COMPONENT HOW’s. These of course form the builder’s WHY, based on which they will BUILD WHAT THEY ARE MEANT TO!
- across all of this discussion, we haven’t even touched on the data. Data is the 4th dimension to all of this – ‘WHERE’. At solution level we talk about where data is mastered and where it is moved to and from as part of interactions. At component level we talk about where a data item can be found in transit (integration) or at rest (database, filesystem etc).
- WHEN is always yesterday – no need to discuss this point.
Note that in smaller organisations, some architecs will wear multiple if not all of these hats. It is however important to ensure that the different perspecitves of a solution are understood and addressed adequately.
For the non-architects out there who have to interact with IT’s most trusted profession, hopefully this gives you a view of the different perspectives that people labelled as “architects” might be viewing things from – if nothing else it will help you understand why they say they are in sync but are constantly arguing!
PS – having written this I think I’ll take another look at the Zachman framework – maybe the penny has finally dropped on what he’s on about 🙂
Welcome – this blog is about sharing and growing our ujuzi:
- our experience – over 30 years in total in the domains of business process improvement and using technology for business advantage
- our knowledge and expertise – accumulated over time, and ever growing
- our skill and technique – how to put what we know into action
We don’t claim to know it all – far from it – this blog is more about an opportunity to get some good old 360-degree review on what we think we do know!