Enterprise Architecture Roadmaps: reconciling across enterprise domains

I was at an industry forum where the discussions focused on strategy realization and roadmaps and some of the challenges with digital strategy execution. While discussing the challenges, many were in agreement that Business leaders are generally well versed in capabilities of IT, and the promise of digital tools and techniques.

Strategy realization involves executing on pre-defined roadmaps, and aligning business processes with appropriate technologies and platforms. In an earlier blog post, I described the process of reconciling Architecture Roadmaps across an organization. (link). This involves bringing together views from across functional and regional domains that coexist along with Business, Information, Data, Applications and Technology (BIDAT) areas. In addition to BIDAT, Architects also need to align across IT Services and digital backbone domains, each with distinct strategic drivers, business sponsorship and execution strategies.  A brief description of each of these along with some of the implications on EA roadmaps follow.

Enterprise-IT - services for internal consumption

Many large enterprises have moved towards a shared services model to centrally support systems and processes for business units and functions that may be globally distributed. IT, along with selected functions like facilities management, HR, finance and production may be managed within the shared services organization.

The enterprise-IT in a shared service will be designed to support internal operations in organizations with thousands or tens of thousands of employees. . These employees will need consistent processes and systems to support business operations, sales, support clients, manufacture and distribute goods in regions across the globe.

The enterprise-IT systems and processes must be continually supported, enhanced and upgraded. A large ecosystem of Enterprise IT application vendors with a variety of tools and technologies offer services for business verticals.

Implication: Senior executives closely watch the SLAs, metrics and cost of operations of enterprise-IT platforms and processes. The costs of operations can influence the organization’s bottomline, and so can productivity gains from transforming some of the processes and systems.

Digital Backbone

In many organizations, the growth engine is driven by distinct capabilities or intellectual property aligned with its core competency. In some organizations, the digital backbone may be called the “engineering” or “technology” capability. At a manufacturing company, the digital backbone will include R&D behind design of products and services. For a media company, it will be the newsroom operations supporting reporters and journalists. At a petrochemical company, the digital backbone will include innovation that drives its geo-information, GIS and drilling capabilities.

Systems and processes to manage core competency have evolved with emerging digital technologies and tools; and these are also likely to be most impacted by digital disruptors in the marketplace.

The past decade has seen entire industry segments and companies disrupted by digital innovators. Ride-sharing companies like Uber and Lyft have disrupted taxi services and public transit systems around the world. A decade ago, low cost online-only brokers disrupted full-service brokerages. Similarly, advances in electric vehicle technologies are being watched by the entire transport segment dependent on internal combustion engines - from automobile companies to oil drillers.

Implication: Technologies that enable the digital backbone are generally customized to the organization’s business processes and can be the engine for growth. Transformation of an organization’s digital backbone can impact the top-line, improve market share and sales, and transform its business model.

Architecting in the Enterprise: Impact on roadmaps

In most of the large enterprises I have worked with, there is a line in the sand when it comes to managing Enterprise-IT services and the organization's Digital Backbone. The platforms and systems are managed and operated independently, but there is value in working across the silos.

Many of the tools, technologies and services are interchangeable across these business units. For instance, a cloud hosting strategy may be applicable across these BU’s. Similarly, the organization will have a better negotiating leverage by consolidating licenses for infrastructure, network, databases and other technology services. Knowledge of Design and development skills may also be interchangeable across the organizations.

The organization’s culture may dictate the level of collaboration across enterprise-IT services and the organization's Digital Backbone.  An effective way to bridge the divide without being constrained by the culture is for technology leaders to continually reconcile Architecture Roadmaps as described in an earlier post. The reviews and reconciliation should be consultative, although some aspects - like external vendor inputs or Technology Debt (link) - may have to be directive. 

--------------------------

Reposted from my LinkedIn Pulse

EA Q&A : Who are the potential stakeholders in an Enterprise Architecture program?

Here are a couple of recent questions that came to me from an online forum -

Question 1> Who are the potential stakeholders in an Enterprise Architecture program? 

 My response follows

The potential stakeholders in an Enterprise Architecture (EA) program may include:

• The Sponsor of EA program - The business, functional or technology sponsor of the EA program will be a key stakeholder
• The Sponsor’s direct reports - Those people will generally be engaged directly or indirectly in EA reviews
• The Sponsor’s reporting managers/executives - The sponsor will engage his/her reporting executives in the EA program
• IS and Technology stakeholders - The CIO/CTO may engage key people from their team for the EA program
• Functional stakeholders - The term ‘functional’ or ‘Business’ is generally broad and may include operational leadership and functional leaders who drive strategic initiatives across the organization
• Functional and operational team members - Do not underestimate the tacit knowledge that can exist in pockets across the enterprise. EA’s may have to engage with a wide spectrum of subject matter experts (SMEs) from across the organization

This is not an inclusive list, but just intended to guide you to explore the list of stakeholders.

After you identify your stakeholders, you will need a Responsibility assignment matrix (RACI) to ensure you engage and communicate with stakeholders.

---------------------------

Question 2> What kind of personal/technical skills are required for an information architect (IA)? I major in information science and planning classes for next semester.

 My response follows

There are many ways of looking at Information Architecture (IA).

• In many organizations, Information gets granular when you engage with specific business, functional or technology Domains. Each will have a specific vocabulary, taxonomy and other business dimensions that you will have to gain expertise in. For example, an IA for a Finance domain may be different from that in Legal or Commercial areas.
• The TOGAF Standard, Phase C: Information Systems Architectures - Under IS Architecture, TOGAF takes into account Data and Application Architecture.

As you plan to major in information science, you could broaden your knowledge by taking some courses in functional domain areas.

Enterprise Architecture career Q&A : What skills to learn?

I came across an interesting question

"How do I change my career from a software developer to an enterprise architect. What skills I should learn?"

My response follows:

This is an interesting question though a lot will depend on your interests and background.
A “software developer” is a very broad term and can range from a core Java/Web developer to include folks configuring and customizing COTS products like SFDC or Oracle Fusion.
There is no indication of the business domain or industry you come from so I will assume you have a basic degree in IS or IT and have a few years of software development experience as a Java or .NET developer.
If you have identified an opening within the EA group in your organization, you will have to evaluate an your understanding of basic EA concepts; for example TOGAF’s ADM (link)


As a software developer you may be aware of some aspects of Information Systems and Technology Architecture, primarily by developing and deploying code to meet business requirements. As an Enterprise Architect, you will have to broaden your horizon to other BDAT dimensions too. Some of it can be done by attending training sessions on EA topics. You should also seek mentoring from EA’s in your organizations or your network.

Note: This is a rather short answer to a question that requires a lot more context about your background and long term goals. My response to similar questions on my blog - How important is it for an Enterprise Architect to have business domain knowledge?

Enterprise Architecture 101: Should Enterprise Architects Offshore re-brand themselves as General Managers*?

During the past few months, I spent some time coaching and mentoring Architects working at offshore development centers. A perennial challenge highlighted by Architects is the lack of 'global exposure' and stakeholder engagement. This is not surprising since much of the IS services – both at captive centers and IT firms – are focused on IS and business services for the global operations of their organizations or clients' business units.

The role of EA in offshore centers can be nebulous, especially in organizations where they lack frequent interactions with a wider group of functional stakeholders. Most of the EAs day-to-day activities focus on servicing requirements from clients or their global teams. In larger organizations, they try to ensure alignment of BIDAT aspects with their global counterparts, but such engagement generally adds a degree of abstraction from their end-users and clients. I am making a couple of broad assumptions here:

• Assumption 1: Architects in many organizations have a hard enough time engaging with business stakeholders; more so for EA's in captive and offshore centers who work with their counterparts or other client facing business partners for such engagement.
• Assumption 2: The bulk of an Architect's time and effort is spent on ensuring solutions are delivered in accordance with agreed principles and guidelines.

Visible aspects of "strategy realization," i.e. engaging in business funded programs and projects is where most Architects demonstrate value. They do this by reconciling roadmaps across functional and technical domains (link). Well defined roadmaps take into account the existing application platforms, infrastructure and processes. Architects also ensure that roadmaps focus on technology enablers, including Non-Functional Requirements (NFR), Integration principles, Data and analytics that will underpin successful digitization.

Follow the money : EA as a General Manager

Successful Enterprise Architecture teams try to ensure stronger Architecture governance by embedding it with the portfolio governance processes. While Roadmaps, Architectural artifacts and solution designs are important, it is equally important for these artifacts to be aligned with platforms and solutions being delivered to clients. After all, the clients and business stakeholders pay for a well functioning solution and not for the 'Architecture' and artifacts alone.

In many organizations, especially among the offshore delivery teams, the term 'Enterprise Architect' is loosely used to denote a senior technical or delivery lead. Therefore, it may make sense to take on the responsibilities and title of a 'General Manager.' Not only does it sound more operational, but in some cultures and organization the title may enable one to engage in broader aspects of Enterprise Architecture, that goes beyond typical 'solution design' activities, and may include:

• Influence and enhance daily operations of the business unit or organization
• Define and track Key performance indicators (KPIs) for a group or division and ensure 'profitability.' Tracking such KPIs and profitability may help influence specific organizational needs.
• Engage with external vendors and wider group of stakeholders on broader organizational strategic planning activities.
• Communicate strategy and results of strategy realization.

In many organizations, Enterprise Architects seem to have a hard time explaining the title and their role and responsibilities to stakeholders. Aligning the role with a title like 'General Manager' should bring them closer to the operational aspects of business, while continuing to influence strategy realization. This will not only enable them to gain credibility with their functional counterparts, but also engage in business funded initiatives they can influence. 

* There is another unintended, practical benefit here too: in large organizations with matrixed reporting structures, 'titles' still matter (even though the HR would like us to believe they are 'flattening' the organization.). In a few organization I have seen my counterparts include titles like "Director, Enterprise Architect" or "Vice President, Head of Architecture," therefore extending the title to include "General Manager" may be the logical next step too. 

---

Thanks for reading! Please click, Like, Share, Tweet or Comment below to continue this conversation | Reposted on my Linkedin blog