By Paul Preiss, CEO and Founder, Iasa Global and David Jones, IASA Ireland, Head European Enterprise Applications, Canada Life Europe (IASA CITA-D)
This article looks at the relationship between business and solution architecture and using it to drive change in the enterprise.
The basis for business and solution architecture
In recent years big picture, top-down technology and software architecture, often called Enterprise Architecture (EA) has been challenged. Notwithstanding some of the sound practices of EA, particularly in the areas of architecture portfolio roadmaps, architecture policies, principles, guardrails and standards, there has been difficulty in demonstrating value to primary (budget and strategy owning) stakeholders and thus becomes exposed to political and actual attacks on its practicality for strategic change and may become misaligned with the strategy and execution plans of the organisation.
Also, the pace of change within industries (innovation, regulation, risk, customer needs, competitive landscape) are driving up the pace of response significantly delivering valuable outcomes in shorter time horizons. Depending on an organisation’s structure, operating model, risk appetite, governance models and capabilities, meeting this increased pace may be a challenge requiring internal transformational and disruptive changes.
Thus EA, which has enjoyed a decade of growth and popularity, is giving way to (or being augmented with) smaller more focused architecture initiatives driven by Business and Solution Architects in a much more targeted way.
Definition of Business Architecture = Digital Transformation
For the purpose of clarity, the definition of architecture is roughly equivalent to digital transformation. IASA’s guiding focus for architecture is based on value-based change, innovation over governance, and people over process. The core capability of the architect is business technology strategy, which is synonymous with outcome-driven digital transformation for most purposes of discussion. The goal is not to oversee and govern change but to be in the thick of it, driving it. It is not to be planning change over 5 years but driving growth over much shorter time periods e.g. 12 months (or less!) using the architect function to augment self-governing teams and drive programmatic milestones which are customer-relevant. This method works as well for non-profit, government and military organisations as it does for-profit companies.
To do this a corporation needs to get the team balance, skills and culture of innovation, digital transformation and human dynamics just right. It is a delicate balance given the architecture team itself must change to enable it to mature.
The goals of a maturing architect capability is not just to speed through change, which can lead to stovepipe business models but to speed the right change and therein lies the core of the value of using Business and Solution Architects (and aligned with EA) and choosing the architects carefully over simple role assignments. The skills, experience and personality to excel in this type of architecture are rare to find in the wild, and even then require years of mentoring to perfect.
Business and Solution Architecture
Driving transformation through business and solution architecture is about practical application, scope management, stakeholder management, and proactive versus reactive engagement.
The Business Architect, just like the Solution Architect, is a business technology strategist. The delivery of technology driven business value is core to their professional capability and career. So for that purpose they share a set of skills/competencies, language, professional goals, and experiences with each other. Any other method of architecture has been shown to fail. Without the shared capabilities and focus the team quickly begins to cannibalise its own value proposition to the enterprise and argue about baseline definitions, purpose and ownership. The level of team synergy and shared community is one of the most important first steps to a mature architecture practice.
With that in place the Business and Solution Architects work very well together and in alignment with the EA from strategy through execution to measured value.
Business Architects must focus on program level outcomes, those that are scoped at the business capability and/or department or region level. These levels are where real business goals and measurements occur and stand closest to the customer while retaining executive authority. There are arguments that this is the IT account manager role, or business relationship manager or similar, but evidence suggests that these roles are necessary to maintain operational aspects of business and technology and thus have little time or necessary skills for the exploratory and experiment based thinking and practice necessary in the delivery of business architecture.
In fact one of the most successful approaches is to pair business architects with account managers in much the same way CIOs are often paired with CTOs. The set of technical skills necessary to navigate, expand, innovate in pure business strategy are too exacting and require constant update thus making the business architect the only sensible person for driving business technology strategy directly with business partners.
Solution Architects are drivers of change execution. They must focus at the product, project or team level to proactively grow, impact, choose, support, and align delivery with optimised business outcomes – which may change during even a two week sprint much less the life of the project or product. The set of skills and experiences necessary to understand business impact of technology decisions are both too great and often too uncomfortable for purely technical staff. While it is possible to create value without an experienced architect it is much more probable with one.
Value Based Change – Digital Transformation
There is much being written about digital transformation but at it’s core it is relatively simple. It is the restructuring of technology (whether or not we call that IT) to directly impact profitability, explore new business models, impact the customer, redefine employee work and culture, and drive optimisation (notice optimisation is last on the list). It is business and growth based over optimisation and savings based and at its core is using technology effectively. In short it is technology at the helm of business as opposed to the traditional enablement role. This transformation is not new and has been going on for years. It has also happened in other areas such as finance, operations and marketing, all of which started as enablement capabilities until they demonstrated top line impact and repeatable results.
The elements of a mature architecture practice are:
- Credibility and relationships with both technical and business stakeholders
- An innovation focus, reputation, and track-record
- A common language and system of value measurement
- Skilled and experienced professionals
- A robust engagement model including tools, coverage, process and artifacts, the relationships between EA (if exists) and the BA/SO and allocation against business domains, capabilities or value streams from an end to end perspective
- A degree of ownership (responsibility, reward and/or authority) over outcomes
A note about executive sponsorship and authority
Many readers of this article will assume they must first have executive support to begin this process but that is unnecessary if the team takes the right approach. Executive support is to be expected if a team is showing direct, measurable and obvious business value. The business to solution engagement method derives its value from its ability to start small and quickly demonstrate this value.