Business and IT Architecture Leaders Deliver Service Excellence

[1]. One implication of a relationship and solution oriented approach is that the IT architect needs to emphasize relationships more than documentation and IT architecture artifact creation. This disconnect between people can develop as the organization[2] matures. This disconnect between IT and business stakeholder mindsets has been the root cause of many perceived failures of IT architecture. If the business and IT stakeholder’s business and organizational views don’t align there is a lot of confusion that results because the underlying terminology used may not align either. The communication style of the successful IT architect provides the leadership and dialog that will bridge these gaps in communication to keep pace with the organization’s evolution.

To understand how IT Architecture can fulfill the vision of true business value, we consider three important elements. First, we examine how the organization’s maturity outpacing individuals can lead to confusion among stakeholders. Next, we can describe the business and IT views that accompanies each level of increasing maturity. As the organization evolves some stakeholders’ mindsets may not keep pace. Finally, we describe how the IT architect’s relationship centered approach builds a shared understanding; a common business reality that enables digital transformation.

Organizational Maturity and IT

As IT and business evolves towards digital transformation, each individual stakeholder that is part of that organization also needs to evolve along with it by adjusting his/her mindset to keep pace with the changes. The root cause of many of the failures that have been blamed on IT architecture are often rooted in a failure to communicate. To evolve and digitally transform both business and IT technology, stakeholders need to work from a shared and common business reality. Four levels of maturity[3] are outlined below and expressed as an evolution towards digital transformation. Each level describes a unique mindset. The stakeholders at each level need to adopt that enterprise to be successful. As the needs of the organization change, so does to the mindset of the stakeholders.

1.    “Business Silos” are the entry level in terms of IT maturity. IT architects at this level are viewed as order takers. Here the architect will typically only present solutions on request. At this level of maturity, the business units’ value solutions in terms of TCO and ROI (possibly risk adjusted) with a business unit oriented view. There are no organization wide measures of value or success yet[4].

2.    “Standardized Technology” is the next level of maturity where the organization begins to realize the benefits that accompany organizational cost reduction and technology optimization. Technology policy alongside overall business driven IT policies are established. While the business units still value basic measures of value there is a question of fit how the business direction fits with the technology roadmap. Overall cost reductions and optimization dialogs between IT and business become increasingly important to build a technology platform that supports the continued and optimized evolution of the business capabilities. At this level of maturity, the IT architect needs to be more proactive as he/she works with business units as a leader.

3.    “Optimized Business Core” extends the idea of an optimized central view on process, data and technology. Overall, technology process optimization and consolidation become more a focal point for business and IT dialog. Speed to market and strategic value become also begin to move to center stage as strategic benefits are factored into the enterprise’s overall value equation. The IT architect needs to be even more proactive and lead the business units to promote the adoption of an enterprise mind-set for business value and what that value means as technology supports the adoption of new capabilities.

4.    “Digital Transformation”[5] emphasizes digital solutions, leverages business service modularity to provide true strategic agility on the organization’s technology platform as well as leverages other technologies like the cloud, and social media to transform customer, competition, data, innovation and value. Only a small percentage of organizations have achieved this level. At this level, business and IT is completely shared where IT architects and business stakeholders view the business value of IT in more terms of innovation and strategic agility.

Disconnected and fragmented views on business objectives also confuses the individual stakeholder. Each person may not understand how they can provide value to the enterprise. An organization, department or group of capabilities may evolve at one rate while the stakeholders evolve at a different pace. Let’s examine a few common disconnects, the symptoms and some suggestions to get everyone sharing the same business reality.

Short Guide to Fragmented Business Realities

Business Silo / Technology Standardization Split Reality

Context: In this situation, the Business Silos organization is evolving into “Standardized Technology”. The enterprise and IT have established technology standards. However, the lack of a shared understanding around how business valuation has now moved more towards a centralized focus of cost optimization and cost reductions may not be shared by everyone.

Symptoms: IT architects present solutions to stakeholders but fail to address issues around common technology platform.

Business stakeholders often get blindsided as the core technology choices evolve or change.

•  Department owners are talking about TCO or ROI and the architects may unknowingly fall into the discussion but fail to address the value that a core technology platform presents. This often manifests when departments express that their needs are not being heard, and often present exceptions to the technology architecture without a clear understanding of the cost impact.
• Business views IT as order takers. For this reason, they often see IT as an obstacle to move around rather than work with. Business stakeholders feel that these standards are obstacles rather than advantages.

What the IT Architect Can Do:

• Address technology platform issues around one-off solutions that may not fit. This includes both value and from a position of future growth.
• When possible include an idea of costs around the non-standard option both for the department and in terms of the technology platform.
• Understand departmental requirements and how they fit against the technology core services and work to build solutions that make sense. Where possible, leverage the core but also advise when it doesn’t fit or needs to be extended.
• Educate the stakeholders on the differences in the mindsets to facilitate better communication. IT architects need to understand that technology core and business value discussion. Business stakeholders need to address overall business optimization justification in addition to their departmental decision processes.
• The IT architect needs to be more proactive and lead a dialog with business units that helps them understand that in addition to an individual business unit’s requirements, the technology platform provides a way to collectively enable requirements across departments. At the same time, the technology platform needs to support the needs across business units.
• The IT architect needs to work along with the CIO as both a leader, diplomat and courtesan to influence change.

 

“Standardized Technology” / “Optimized Business Core” Split Reality

Symptoms: IT architects and business stakeholders understand common use of technology across the organization. Unfortunately, the discussion around departmental requirements has remained very solution oriented with IT being viewed strictly as a platform to deliver business capability. This evolution moves the dialog not only around the business unit technology, process and data but also around organizational choices. Enterprise wide business valuation becomes more important with an emphasis on using technology as an enabler to improve business capability. Process, data and organizational change are just a part of the dialog now along with technology.

Unfortunately, some business stakeholders may be locked on to a fixed technology mindset and refuse to make changes outside of that. Business stakeholders often provide business requirements that they simply expect the IT architect to use to build a solution without consideration of the technology. The problem is that the architect may unknowingly accept a role as an order taker and fail to identify and deal with key technology issues that involve an understanding of the technology landscape and the organization’s technology road map.

• Decisions around process and data are not made to reflect what makes sense for the entire organization yet because there is no valuation around the overall optimization.
• Department owners are talking about TCO or ROI and the architects may unknowingly fall into the discussion but fail to address the value that a core technology platform presents. Exceptions to the architecture process are based on perceived business process / data uniqueness issues rather than technology issues.

What the IT architect can do:

• Address technology platform, organizational business process and data issues around both solution and service delivery. This architect needs to consider the technology landscape and the organization’s technology adoption road map to make the best possible recommendations. The dialog is about how technology adoption for solution value today enables strategic agility and value creation for tomorrow.
• Review business service delivery and identify services that should be preferred. Sometimes these are used by the architects as a service catalog to support the reuse of business services.
• If possible, include some direction around business model innovation. How can the overall process, data and standardized technology be revised to ensure business and IT are aligned?
• Educate the stakeholders on the differences in the mindsets to facilitate better communication. IT architects need to understand that standardized technology, service reuse, process improvement and data consolidation are important factors. Business stakeholders need to address overall business optimization justification in addition to their departmental decision processes. Business model innovation enabled through technology becomes increasingly important as the organization evolves to support true “digital transformation”.
• The IT architect is a leader that needs to articulate the triggers for change and how that change can be made in the organization. The IT architecture touches people, process, data and technology. Most important the IT architect has moved to the position of a trusted advisor in their dialogs with the business stakeholders that also includes the enterprise’s executive leadership team.
• The IT architect needs to work alongside the CIO and business stakeholders as respected thought leaders and visionaries to enable real digital transformation across the enterprise.

Summary

The resulting symptoms of a mindset difference between the IT architects, the CIO, IT and the business stakeholders can often fragment as the growth of an individual stakeholder may not keep pace with the evolution of the organization. The IT architect needs to recognize that each person may be coming from a different mindset and work to communicate a common business reality to all stakeholders that is appropriate for that enterprise’s level of maturity. To make this happen the IT architecture team needs to both build on its competencies and educate all stakeholders across the organization. As the organization matures the IT Architect will need to mature to build a more proactive mindset and through a leadership stance address the concerns for the appropriate level of maturity.

References:

[1] See Brice Ominski and Scott Greenlay for an article that describes the evolving role of the CIO: from soldier, captain to general. The general is the most effective leader and builds true business service excellence in the enterprise. http://www.mnp.ca/en/posts/taking-charge-as-a-general-cio-to-lead-your-enterprise-in-the-digital-economy16

[2] This can also speak to much finer granularity. An organization, department or even set of capabilities can mature faster than the stakeholders can adapt.  Without conscious guidance, the stakeholder communications often becomes ineffective.

[3] The maturity levels here have been adopted to reflect today’s mindsets … from Enterprise Architecture, Creating a Foundation for Business Execution, by Jeanne w. Ross, Peter Weill, and David C. Robertson. 2006. Harvard Business School Press, Boston, Massachusetts.

[4] Smaller organizations that are not silo-ed may find that they can avoid this level in the classic sense. Instead, individual programs may become the individual silos. In larger organizations, business unit and program silos can both be present. At the entry level silos present themselves as obstacles to an organization wide approach to business valuation. Silos are however an important evolutionary step because they drive out the idea of solution architecture.

[5] This was referred to as “Business Modularity” in Enterprise Architecture, Creating a Foundation for Business Execution, by Jeanne W. Ross, Peter Weill, and David C. Robertson. 2006. Harvard Business School Press, Boston, Massachusetts.

Join Brice Ominski for his eSummit presentation on 11/16 https://itabok.iasaglobal.org/november-2016-esummit/

 

Originally posted on Brice Ominski’s Linkedin: https://www.linkedin.com/pulse/business-architecture-leaders-deliver-service-brice-ominski?trk=prof-post