The Balancing Act of Architecture
From the archive: written before or outside the Architect Tomorrow newsletter, so it may be out of date.
My perspectives on effective Architecture have changed somewhat following a year in a Architecture Governance role in a heavily regulated industry. I believe one of the key things an effective Architect does is pragmatic balancing of different concerns - and it’s what makes the role very difficult (if not pretty much impossible) to truly master. Here are some of the key things that need to be considered and balanced:
Balance between strategic and project focus
Balance between strategy and project - pragmatism in balancing project delivery timescale pressures and holding firm to achieving the desired target state for the organisation. Examples of this are projects taking decisions on implementing re-designed/optimised business processes or technology platforms as this will incur delays and additional costs to the project. However in some cases they are only seen as delays if they are not planned and discussed upfront with stakeholders and agreed as in scope. But then of course this turns in to conversations about de-scoping strategic implementation options in order to deliver quicker! My article on the SATO model relates to this. Also covered in my article - EAs are you providing value for money?
As an Architect the day to day reality of this is deciding should you/the team provide:
- Project specific guidance and consultancy to enable a specific instance of a solution to work (So either Solution Architecture or guiding and enabling Solution Architects).
- Creating documentation, collateral and supporting strategic guidance (Architecture Assets / building a Repository) that will guide many projects that have similar questions.
- Both - Ideally you have roles / resources to do both. Although if rotated across both aspects; Architects tend to be more rounded and pragmatic as a result. The old saying of walk a mile in someone else’s shoes really applies here!
Specialist expertise vs Emotional Intelligence
Balance being a technical SME (Subject Matter Expert) and soft skills / emotional intelligence - i.e. being really knowledgeable about Application Architecture (or any other subset of Architecture) but also being able to communicate the so what around the key points to a range of stakeholders.
This also relates to balance between depth and breadth of skills that Shaun McCran talks about in this article.
Business vs IT Architecture
Balance between business value focus and seeing technology potential. Whilst everything Architecture work on should have business value - sometimes realising business value doesn’t start with focussing on the business. It can come from looking at what the latest trends are, what your competitors are up to (but you do of course need to be careful not to be swept up in hype or “copy cat” type initiatives). You also need to think about the ecosystems the business operates in and whether a platform strategy makes sense for your organisation.
Guardian vs Disruptor
Protecting the integrity of existing Architecture vs enabling Innovation. How you allow for innovation - for example opening up APIs that enable 3rd party developers to build new apps based on your capabilities - in a way that doesn’t bring down your core internal systems. Balancing and mitigating that risk through intelligent choices in your architecture.
Customer vs Employee experience
Customer Experience vs Employee Experience (and other considerations). How do you deliver fantastic experiences for your customers in such a way that doesn’t cause massive headaches for your teams. Some might be tempted to paint over the cracks in legacy architecture by getting customer facing staff to use multiple systems and different processes. But that creates a living hell for your employees that hits employee satisfaction - that in turn can have a knock on impact on customer experience.
Centralised vs Federated
Centralised vs Federated - this could be (but not limited to) the central Corporate IT department vs Planned (and Governed) Embedded IT within business units. Or it can be Corporate IT vs “Shadow IT” - ungoverned IT implementations undertaken by business units. Equally it could be about other capabilities - how much duplication do you tolerate as it’s been done as a trade off?
Controlled vs Fast
Following the process and governance vs focusing on delivery - I plan to write another article on Pragmatic Governance - so keep a look out for that. This relates to point 1 (and many others) but is more about ensuring you minimise / mitigate risks through appropriate controls and checks and balances. Some refer to it as 2-speed IT delivery but it applies to more of the transformation teams than just IT.
What else?
What other key balancing acts do you think effective Architects provide? Or other related roles (such as Change Management or Transformation?) Please share your thoughts via a comment or a message to me - would be great to hear from you.
Originally published on LinkedIn. Comments and discussion live there.