.png)
Alignment between Business & IT
Enterprise Architecture at its most fundamental level involves alignment between business and IT.
Traditionally and in most cases today, the function sits within the IT organization; usually under direct remit of the CIO. Of course, this means that the Enterprise Architecture department is run by and staffed with an IT ‘crowd’ – think for a moment about the professional backgrounds of your own organization’s Enterprise Architecture team. Your cohorts likely come from operational IT backgrounds – data management, process management, and of course, software architecture. This makes sense. The practice of Enterprise Architecture requires a deep understanding of the moving parts that make up an enterprise’s technology landscape. What this often means, however, is that most Enterprise Architecture teams in practice don’t have enough interaction with their colleagues from ‘the other side’ (the business, that is) on a day-to-day basis. You can probably relate to this on some level or another.
Enterprise transformation is a journey, and one that is (and indeed should be) driven by Enterprise Architecture – but that doesn’t mean
that IT can do it alone.
It’s not easy to deliver real business benefits from transformation initiatives. When the remit of Enterprise Architecture is limited to cost-reduction exercises, risk mitigation and escalation management, the department sits with a reactive focus and is generally seen by the business as a hygiene factor. This ‘commodity’ status is, of course, a separate challenge for Enterprise Architecture practitioners – obliged to deliver tangible value year-over-year in some sort of IT ‘race to the bottom’.
Conversely, Enterprise Architecture departments with a clear strategic foundation take a proactive approach to implementing forwardlooking transformation initiatives and new business capabilities. It would stand to reason then that almost every EA practitioner strives towards an idealized version of this ‘proactive’ architecture.
The reality is of course much less defined. There is no such thing as a purely reactive EA function. Even in the toughest of firefighting situations, there will be projects focused on future optimization and enablement. Nor does every proactive and strategically aligned architect achieve perfect project outcome every (or even any!) time – there will always be projects prioritized poorly, or ineffective governance guidelines that cause confusion for architects or developers on the ground. When you evaluate the common challenges behind this, you will notice a common theme:
Enterprise Architecture cannot be effective without truecollaboration with the business.
Common challenges of non-Collaborative Enterprise Architecture
business.
Challenge 1: The Enterprise Architecture function that never leaves the ivory tower
It’s an all-too common stereotype, but unfortunately some Enterprise Architecture functions do still operate without a clear grasp of the real operational details. It’s vitally important to foster strong and collaborative relationships with the people affected by architectural principles and policies.
When frameworks or guidelines are created in isolation, Enterprise Architecture can (and will) run into a myriad of barriers that minimize effectiveness. It can be easy to disregard technical details and practical feasibility, but what may seem like the smallest concern during design stages can render an entire project’s governance practically useless.
As well as giving the architects a limited view, operating in a silo can also damage the reputation and even credibility of an Enterprise Architecture department. Without colleagues involved in the decisionmaking process, buy-in for important initiatives is difficult to achieve and governance even harder to ‘enforce’.
In this scenario, stakeholders from within the business, and even colleagues within IT begin to view Enterprise Architecture as a cost-center that adds no value and makes their life harder. As a result, project leaders and program managers will attempt to sidestep the department for fear of being slowed down or hit with impractical guidelines and policies. Initiatives that don’t align with the organization’s strategic goals may kick-off under the radar with zero Enterprise Architecture involvement, or sub-optimal technology may be purchased outside of Application Portfolio Management (APM) guidelines. The worst part? The Enterprise Architecture function safely ensconced in the ivory tower won’t realize until it’s too late.
These are, of course, ‘worst-case scenarios’. Most of the time, it’s a combination of smaller blunders and miscalculations that keep an Enterprise Architecture department’s
performance at good, rather than great.
In this scenario, ways of working and modeling languages can also cause problems. With the best will in the world, a data manager will
struggle to make sense of – let alone contribute to – models developed in ArchiMate®. Project architects will give up and contribute only the bare minimum to templates or questionnaires that refer to unfamiliar taxonomy. And is the definition of that application component understood in universally the same way by every stakeholder?
Challenge 2: The ambitious (and ambiguous) long-term visionaries
It’s no secret – today’s modern enterprise operates with an
overwhelming pace of change. There is a need to balance the longterm vision with short-term, operational benefits.
Enterprise Architecture departments with close ties to the C-level anda lack of interaction with executors ‘on the ground’ have a tendency to overlook opportunities for optimization in the as-is architecture; instead choosing to focus almost solely on the organization’s longterm vision and north star, utopian future state.
While a long-term strategic roadmap is absolutely crucial for anyproactive and progressive Enterprise Architecture team, laser focus on projects that project multiple years into the future – with little to no short-term return on investment – do little to help Enterprise Architecture’s credibility with the wider organization.
And it’s not just operational colleagues and stakeholders that struggle to get on board with lofty goals and an aspirational future vision.
Too often, these forward-looking initiatives are documented in too vague a manner for managers and team leads to identify with – even the architects’ colleagues in IT. The stakeholder wants to know: “What’s the impact on our day-to-day?”
In this scenario, executors become overwhelmed by the over-ambitious plans and future-state architecture visualizations which seem to bear zero resemblance to the today’s current operational reality.
When you add to this the drawn-out process cycles of traditional Waterfall methodology and the ivory tower challenges touched on in Challenge 1, it’s no surprise that the ambitiously (and ambiguously) visionary Enterprise Architect struggles to articulate exactly what business value will be delivered in the short term.
Challenge 3: Stuck in the weeds
On the opposite end of the spectrum, due to the operational backgrounds of many Enterprise Architects, there is also a risk that the function can retain too much of a focus on the IT-organization. These teams rely on tactical plays with little strategic input from the business – which is what is really necessary to position IT as a promoter of innovative value streams and business models.
This lack of strategic planning sets the Enterprise Architecture function squarely in firefighting mode:
responding to change requests and prioritizing quick wins (which may deliver operational efficiencies for IT but offer little added value above that).
Luckily, in reality, we know that technology is fundamental to differentiating the business’s capabilities and strategic proposition, and as Architects we strive for a holistic overview of the entire organizational landscape and the translation of strategy to implementation.
The wisdom of crowds: What does Collaborative Enterprise Architecture look like?
And so we come to potential strategies for Collaborative Enterprise Architecture.
We know that an optimal Enterprise Architecture function involves and collaborates with every stakeholder – from functional contacts across the business to the IT crowd on the ground, from management to the project office, from the C-suite to the Enterprise Architects themselves.
We also know that, far too often, Enterprise Architecture takes place in isolation from these key stakeholders. How can we do better and avoid falling into one of the traps mentioned above? The crucial component is thoughtful collaboration between Enterprise Architecture and (all) their stakeholders. Without collaboration, organizations run the risk of producing multiple, individual plans that compete with one another. Without collaboration, planning becomes a time-consuming and expensive box-ticking exercise.
By creating a feedback loop and a clear communication cadence or cycle that brings all stakeholders together and facilitates collaboration, Enterprise Architecture can become a much more strategic partner to the business, with full visibility of strategic objectives and priorities. By capturing the high-level vision together with on-the-ground reality, Enterprise Architects can start to break down those notorious ‘ivory tower’ walls and work on architecture that delivers deeper business impact. And by taking a data-driven approach, this collaboration will result in solution-oriented planning that aids the CIO in facilitating strategic objectives without neglecting operational requirements.
While a communication cadence can consist of regularmeetings, iterations or workshops, it doesn’t need to take that form.
Consider your Enterprise Architecture tooling
Enterprise architectures are not uniform or inflexible. They comprise a medley of data, processes, applications and infrastructure – managed, maintained and contributed to by multiple functional owners and stakeholders from across the entire organization.
Architectures consist of multiple layers: from high-level to absolute detail and everything in between. They’re built with business capability elements that span multiple organization functions and disciplines, each of which exists across many different architectures itself. Enterprise architectures are complex systems. Changes do not take place in isolation.
It’s vital that your tooling prioritizes an architectural repository – one that is navigable across these multiple dimensions, functions, and disciplines, and that integrates the organization’s data, models, objects, processes and projects.
Drawing on a central repository not only allows Enterprise Architecture to access this interrelated information, but stakeholders to more easily collaborate on its maintenance and management. It allows architectural data and models to be recycled, and the assurance that they are always up to date. It facilitates much easier multi-dimensional visualizations of the architectural layers. It enables stakeholders to gain insights on the information most important to them – whether that’s high-level strategy or the attributes of a specific application integration.
It’s also worth noting that it’s not enough for such an architectural repository to just exist. The tooling needs to facilitate real ease-of-use and value for all stakeholders in order to safeguard input, compliance 10 and buy-in. It needs to facilitate the data-gathering process and bring time and resource efficiencies. It needs to effectively enable multiple stakeholders with multiple use cases, and help architects visualize and plan the relationships between them. And ultimately, it needs to bring together the processes, data, applications and infrastructure that are so inextricably linked throughout the organization so that Enterprise Architecture can truly guide the enterprise with agility.
In Enterprise 2.0: The Dawn of Emergent Collaboration, McAfee described social software as a means of collaboration in an enterprisecontext. Enterprise Architecture tooling is certainly no exception.