Software Architect as a Service
Why planning the near-future is important
Software architecture is a concept that often misunderstood. Let’s come up with the following
Software architecture is the understanding of a system and the constituent parts defined by a set of qualities.
Why is thinking about software architecture important? Well, take the case of the arrangement of a city and the necessary resources. Athens in Greece is a good example of a city where “organic architecture” was applied (or not) as opposed to Copenhagen in Denmark which is referred to as one of the best planned cities in the world.
If you don’t:
- Consider about the future;
- Think about what may vary or change;
- Future-proof (to some degree) your current estate
Then you’re likely to run into problems when it comes to change — which means greater cost, productivity problems, tech team turnover or inability to compete in a market.
Fundamental Components and Help
Let’s look at some fundamental components of software architecture as part of this article.
- Architecture Viewpoints;
- Non-functional Requirements;
- The Software Architect Role
By the way : ) I provide this advice, guidance and support through a “software architect as a service” offering via hwintegral.com — more on that later.
Architecture Viewpoints
I split systems into four viewpoints:
- Business View — the business processes to be supported by one or more systems;
- Data View — the data processes to be supported by one or more systems;
- Infrastructure View — the view of the entire system in terms of applications and how they talk to each other
- Technology View— the underlying technology view of the system
Let’s refer to this as BuDInT to provide a definition of a system.
Non-functional Requirements
Across those four viewpoints there are several characteristics that it is important to you as a business. We call these “non-functional requirements” which are present within your “software platform” in varying qualities. I’ve written about these and the OPAQ methodology before here:
This is how you define your system in terms of scale, performance, testability in addition to an important quality “productivity” — which is how productive your team are on the current codebase.
The Software Architect Role
You may have heard the expression “architect is a role, not a title”. When we’re concerned with software architecture or architecture of a specific application it may well be the case that the role is played by someone on your team. That is fine in itself, but as the team grows you’ll reach a point where you need to split the team from an organisational point of view. 5–7 people on a team is really the optimal number.
When you do split your team you’ll need to organise teams around “something”. That might be a functional split of a system or a product split. What-ever you choose to do you will need to introduce some co-ordination if the teams are working on the same product. In that case you’ll have two people playing the “architect” role and co-ordinating via some sort of group — possibly the architecture guild.
As the team and company grows you’ll see additional needs appear in terms of co-ordination effort. As the array of products within the organisation increases it becomes impossible for just an engineer within each team to keep track of everything via a guild. That often leads to a full-time architect or software architect being required to manage the process of procuring software, doing vendor analysis and understanding the integration effort into the software estate. The term(s) bandied about here include Solutions Architect andEnterprise Architect. Those people are great, but how they work and remain current is often a problem.
If your company is product based but requires significant customisation and implementation effort for specific customers then the “Solutions Architect” role is needed.
I did a presentation a few years ago about The Role of the Architect in Berlin at the CTO meetup. You can find that here:
About Me
I’m a CTO and software architect with 15+ years experience as an engineer, software architect and consultant. I’ve spent time as an engineer performing the “Technical Architect” role as well as coaching and co-ordinating across multiple teams to bring together viewpoints and plan the future of systems in terms of their technical architecture.
I’ve spent time as a Solutions Architect providing advice and implementing products customised to specific customer needs — especially in the eCommerce, health-care as well as others.
I’ve also spent time in the Enterprise Architecture space in larger 1000+ people organisations where there are closed to 100+ systems in play supporting many different departments.
Hiring a full-time architect is costly, but the experience they have can be invaluable. I offer a part-time Software Architect as a Service function through my consulting business. That involves:
- Software Architecture Review — for planning (e.g. for scale), to identify problems and potential blockers to growth;
- Software Platform Roadmap — analysis and construction of a platform roadmap for building capability, address non-functionals, technical debt and negotiation with the product roadmap.
- Software Architecture Coaching — sprint or time based (every month, 3 quarter) to help with operational planning and execution of a roadmap.
More about the Software Architect as a Service here:
