Showing posts with label technological innovation. Show all posts
Showing posts with label technological innovation. Show all posts

Monday, August 14, 2017

Enterprise Architecture 101: Digital Strategy Execution enabled by an ARB

A while ago, I had blogged a Pulse article about Digital Strategy Execution (ref link). This is a topic I continue to observe and reflect on since organizations continue to execute their corporate digitization strategies.

The Editor at Cutter Consortium reached out to me asking if I could expand on the topic, especially in the context of Architecture governance. This viewpoint - Digital Strategy Execution via Architecture Review Board (ARB) - was recently published as an executive update by Cutter Consortium.  I realize the report is firewalled, so for those without access to Cutter’s subscription, here is a detailed summary. I have also posted some of the diagrams from the report in a slideshare (link)
Enabling digital strategies requires CIOs, Enterprise Architects and IT leaders to engage with business stakeholders. Such engagement of IS with business stakeholders must be governed by the organization’s processes, operating model, and technology governance to ensure robust, scalable architectures. The resultant roadmaps should also be governed by a well-functioning ARB.

Digitization and Information Systems

There are lots of discussions and viewpoints on ‘digital strategies,’ and they must be contextualized for an organization. Examples of such user stories include medical insurance companies motivating consumers to video-chat with doctors, auto insurers offering “usage-based insurance” after analysis of driver data from devices on cars, and banks minimizing foot traffic at the branches while enhancing digital transactions. As an enterprise architect responsible for governance at a multinational organization, I had an opportunity to review several digital transformations. Most of them seem to fall into three distinct categories (see Figure):




  • Lights-on digitization (a.k.a IS led digitization)
  • Digital excellence
  • Customer-centric digitization

    Most lights-on digitization efforts - like migrating application platforms to cloud hosting, introducing new software as a service (SaaS), enhanced data management, automation of existing processes etc - are driven by IT leaders, who should take the opportunity to align these with other transformations.

    Technology and business leaders continually scan the external landscape for new and innovative solutions. Digital excellence initiatives include the introduction of innovative vendor solutions that can drive business growth. Examples include use of blockchain technology, tools to analyze big/unstructured data; speech recognition and interactive voice response (IVR) enabled processes, and incremental use of virtual assistants and transcription or translation services.

    Customer-centric digitization programs aim to enhance digital engagement with the company’s customers, business partners, vendors, suppliers, and other third parties. These initiatives require strong business insights and are generally sponsored and steered by senior executives. IT leaders facilitate ideation and technology foresight, and ensure seamless introduction of these solutions.

    Customer-centric digitization might also be designed to address threats from digital innovators. For instance, the travel and hospitality industry is reacting to disruptors like Uber, Lyft, and Airbnb. Innovations in robotics, Internet of Things, and artificial intelligence–driven planning and modeling are beginning to disrupt the existing ways of working in manufacturing industries.
    In the report, I expand the context of Architecture Governance (figure) and execution that requires executive support and an operational cadence. Digital strategies and roadmaps continually evolve and change in response to economic conditions, changing customer preferences, competitive pressures, and external market forces. Therefore, the basic design of an ARB should be simple but extensible. Please feel free to review the references:

    Thanks for reading! 
    Please share your views on Digitization & Governance. You may Like, Share, Tweet and Comment below to continue this conversation | Reposted from my Linkedin Pulse blog |

    Tuesday, April 12, 2016

    Vendor-Driven Technical Debt: Why It Matters and What to Do About It

    IT Leaders continually strive to balance the diverging needs of the organization, trying to address the “innovate vs sustain” challenge. They need to ensure that the limited resources support the existing investments in technologies, systems and processes while also enabling innovative techniques.
    One of the key challenges in sustaining technology landscape is to ensure “technical debts” are paid off.


    The term technical debt is generally used to describe the burden created by decisions to cut corners during design and coding software. The catchy metaphor is attributed to Ward Cunningham, who helped us think about how quick-and-dirty solutions set us up for debt that has to be paid back with interest. Technical debt driven by software vendors is a less frequently discussed, but significant variation on the theme.

    In a recently published article in Cutter IT Journal, I try to broaden the conversation around technical debt to include the challenges of keeping up with software vendors’ lifecycles. Such vendor-driven technical debt requires the continual attention of CIOs and technology executives who need to balance limited budgets to address the issue.


    This seems to be a persistent challenge fellow Enterprise Architects face in other organizations too. For instance, a query in a recent EA forum generated nearly a dozen responses in a span of a few days.  Damien Malone’s queries on tracking technical debt - How do I track? What do I track? - yielded a range of ideas.

    Crux of the problem

    Enterprises of all sizes buy or license software products, solutions, and tools from vendors. These products range from small investments in worker productivity tools to large investments in ERPs, CRM, databases, and specialized solutions designed to meet specific functional needs. The decision to implement a version of the software  — for example, Oracle Database 12c Release 1 or SQL Server 2008 R2 or SAP ERP 6.0, EP 4 — is generally a strategic one, requiring considerable analysis, planning, and resources. Such decisions are taken at a point in time, while considering the organization’s business needs and constraints in the technology landscape.


    Software vendors and solution providers continually upgrade their product offerings, promising newer technical and functional capabilities. In order to provide support, vendors expect clients to keep up with their upgrade cycles. Upgrading to a newer version of software recommended by the vendor requires deliberate impact assessment to understand the potential impact to systems upstream or downstream. Such an upgrade may have to be orchestrated with changes in the rest of the landscape; for example, during a large pre-scheduled program.


    After a few cycles of not upgrading, the software may fall behind the vendor’s support cycles, and the vendor may demand a penalty for supporting older versions. Some vendors call this “extended support,” and it can be expensive.  In some cases, after adequate notice, vendors may stop support of versions going back several generations.


    Note: a more detailed analysis of this topic and techniques to address and repay technical debt are in my Cutter IT Journal article “Vendor-Driven Technical Debt: Why It Matters and What to Do About It (link).”


    Cross post from my LinkedIn Pulse article