Skip to content

Kaine

Defining Digital Architecture - Shifting the Focus to Customer Centricity

The digitalization of industries has created the need to define a new type of architecture, one that provides a robust foundation to enable change. As of now, the term “digital architecture” does not have a common industry definition. Nonetheless, with the emergence of digital technologies and the demand for increased business agility, some industry frameworks have emerged to guide the definition of the term. This article provides context for the definition of digital architecture and reveals that customer-centricity is at its core.

What is Digital Architecture?

The concept of digital architecture has been used to describe aspects of IT architecture that emphasize the use of digital technologies to achieve business outcomes. Although this emergent field has not yet been fully defined, the digital revolution has heavily influenced it.

Several known architectures deal with design at different layers. Enterprise architecture (EA) deals with planning from a strategic, big-picture standpoint and comprises various domains. The business architecture domain explains how a company needs to operate to achieve business goals. Data architecture provides an understanding of how to address data management issues. Application architecture deals with application models relevant to business functions, while technology architecture manages the structure and interaction of platform services with logical and physical technology components. Finally, solution architecture glues all the domain architectures together around a particular solution.

Digital architecture is more an architectural discipline applied to solution architecture than an architectural domain of its own. It is a discipline that redefines the solution design process and shifts the focus from the business problem to the customer experience. Digital architecture involves internal stakeholders shifting paradigms from thinking of solutions from within to fully incorporating external stakeholders (customers) in the solution design process…

You’ve got to start with the customer experience and work backwards for the technology. - Steve Jobs

This article is published in the Cutter Business Technology Journal.

Read the full article here.

Photo Credit - Zach Lucero on Unsplash

Pull Together or Fall Apart - Startup Culture and EA Adoption

Introducing an enterprise architecture (EA) that enables digital business strategies poses challenges for startups. In this article, I discuss how a startup’s culture plays a part in overcoming these difficulties, outline the steps involved in adopting an EA framework, and show how implementing an EA practice can help such businesses evolve.

On Startups and Strategy

Startup culture focuses on time to market and business agility. The perception is that time to market is vital to staying competitive, and founders are usually so busy formulating their business and product strategies that they do not pay attention to aligning their culture to the vision. This disconnect often leads to an inability to execute on such strategies because behaviors are the enablers of the strategies and are required for any change initiative to be successful. Without shared values, beliefs, and teamwork, people cannot come together to execute strategic objectives. Enterprise architecture defines the process needed to align the culture with the strategy. Establishing an EA capability within a startup ensures that, through its culture, people, and processes, the organization can implement its formulated strategy.

So how can you execute on a strategy that ensures that your startup will survive in five years? An effective strategy will promote innovation while ensuring coherence across the enterprise. Founders and executives often realize the need for standardized processes to achieve this unity and company maturity later on. But an EA can provide this standardization and value if founders integrate it as part of their firm’s culture from the outset. This involves organizational design, which must jibe with the core values that define the business vision. Such integration could be the difference between being a successful company or a failed startup five years down the road…

This article is published in the Cutter Business Technology Journal.

Read the full article here.

Understanding the Complementary Relationship Between Enterprise Architecture and Project Management

Project management frequently develops business user needs to include technical and functional requirements. Whereas, enterprise architecture (EA) employs a method of producing technical standards and business operational needs. Successful companies are beginning to integrate both functions by ensuring proper data flow between them and common language and taxonomy is used to establish consistency by extending dimensions between both organizational units. This post gives a perspective of the different views and complementary relationships between an Enterprise Architecture (EA) function and a Project Management Office (PMO).

Complementary Business Functions

The Enterprise Architecture Body of Knowledge defines enterprise architecture as a practice, which analyzes areas of everyday activity within or between organizations, where information and other resources are exchanged to guide future states from an integrated viewpoint of strategy, business, and technology. The responsibility of Enterprise Architecture is to assist business leaders in vision, mission, capability, goal and objective identification leading to the creation of business models and processes describing the structure of the enterprise. This structure includes the people, process, and technology required to fulfill the business mission while achieving the business vision through select business goals. These select goals are then completed through Project Management. EA identifies dependencies to the achievement of these goals which are needed by project management for project planning; these goals are similar to project milestones in the traditional waterfall methodology, and EA only facilitates this process through the application of best practice techniques.

Enterprise Architecture creates roadmaps as a deliverable to establish the relationships between business capabilities and business goals. The method lists individual work packages between the current processes (the baseline architecture) and future state processes or goals (the target architecture), dependencies and analysis of the gaps, and shows a progression of how these goals will be achieved. Goals expand the business vision. Goals are milestones required to realize the business vision. Enterprise Architecture also promotes discussion and provides a process between the Project Management Office (PMO) and the business leadership to create an executable roadmap to ensure achievement of the business vision. In the nonexistence of an EA function within an enterprise, a PMO may use business analysis to assemble IT requirements that support business goals; showing where EA and the PMO may intersect. At the project or solution delivery level, enterprise architecture supports project management, by defining work packages included in a project management plan. Project teams reference a catalog of work packages to ascertain tasks needed to be done to achieve the set goals. These work packages help with resource management, a key element to activity resource estimating and project human resource management. Both are essential components of a comprehensive project management plan to execute and monitor a project successfully.

Enterprise Architecture is a consultant to business leadership and the project management office. Working directly with business leaders, EA creates a structure proposal to capture the business needs such as purpose, vision, mission, capabilities, business goals, scope, process, functional needs, and objectives to complete the business architecture. Upon approval, the business leadership authorizes the delivery of the business architecture to project management. Project management uses the business architecture to plan implementation (product development, contracting, coordination of resources, planning, outsourcing strategies and so on). If project management identifies required changes to the business architecture deliverable, project management coordinate with EA to make necessary approved changes. Requirements are managed using a Requirements Management process. As described in the TOGAF 9.1 specification, this is used to manage architecture requirements identified during any execution of the Architecture Development Method (ADM) cycle.

There are always two sides to a coin, and some may argue that both disciplines do not intersect. From an information technology viewpoint, EA differs significantly from project management. EA includes non-technical areas such as organizational and business process; topics that do not primarily concern IT. EA also assists in the establishment of a clear understanding of the business environment, also known as the important business outcomes. EA is responsible for the structure, documentation, and modeling of the enterprise while the PMO is responsible for planning, monitoring, and reporting of work packages. The architect models the enterprise and establishes principles for transformation, standards for technologies, and the roadmap for the business with the aim of achieving the target architecture or business goal. After receiving the transition architectures, dependencies, roadmap, risks, the work breakdown, skills and resources and deliverables from EA, the PMO has to come up with a project plan and iterate it until the schedule, resources, and costs are in sync. The PMO has then to monitor and report progress, impediments, risks, and required changes to these architectures. But, asides these differing perspectives we can still argue that objectives of both functions are pretty similar; The following lists out the overlapping objectives of both functions;

  • Strategy: It is an adage that EA ensures business and IT strategy alignment while PMO supports strategic planning

  • Investments: EA influences approval decisions and budget formulation when it comes to business investment. PMO supports the budget formulation process and monitors investments

  • Governance and Review Process: EA is a member of the review process, project portfolio planning and review board which governs project performance against scope, schedule, costs, risks, and quality. PMO leads this review process and adds new projects to project portfolios, monitors and reports risks, issues and performance problems

  • Acquisitions: EA ensures IT assets align with target architectures and technology standards, promotes re-use and provides acquisition support. PMO supports development of procurement package through cost estimates, Request for Proposals and selection plans

Both disciplines are complementary, but the domains and work products are different, and the outcome between the two is a collaborative effort.

It is clear that Enterprise Architecture is a way of using system thinking as an instrument to integrate and align all organizational levels; from strategic to project level, against a primary objective. EA recommends solutions that help the organization attain its goals, and to continually govern the implementation of these solutions to meet business goals and objectives. However, Awareness of the subject of Enterprise Architecture tends to surface in the Enterprise through IT, the Information Systems (or Information Technology) Community. This lack of awareness is a perception that business leaders need to address to gain value from EA.

Creating Business Value

To build a case for integration, EA and the PMO have to focus on outcomes that will validate the business value collectively. These results are achieved by improving the project selection decisions by adequate prioritization of the project portfolio using Project Portfolio Management (PPM). PPM is the centralized management of the processes, methods, and technologies used by project managers and PMOs to analyze and collectively manage current or proposed projects based on numerous key characteristics.9 Determination of supported future business capabilities is supported, and alignment with strategy and architecture is also required.

EA has to ensure that the PPM provides key deliverables to the architects. Ways of achieving this include proposed project and business case meetings, shared project dependencies reports, project fulfillment of EA requirements before commencement, a unified PMO and EA governance process, and involvement of EA in project design reviews. On the other hand, the PMO has to ensure EA provides key deliverables to project managers by delivering the enterprise context for every goal at the project or solution delivery level, collaborative project change proposals, project developmental assessments, and well-defined enterprise architecture road maps showing how such goals fit into the bigger picture via transition architectures.

To sustain value, here are business exceptions that EA and PMO must solve:

  • Increased focus on business value: Both functions must understand and translate business strategy into strategy execution.

  • Increased knowledge of business and information architecture.

  • Improved collaboration and fewer silos.

  • Focus on prioritization: Strategic enterprise goals must be understood and followed.

Strategy execution happens when EA receives business direction from the business planning which in turn gives a structured guidance to portfolio management (program and project management). Capability planning using this model leads to strategy execution.

Conclusion

Successful companies are beginning to integrate both functions by ensuring proper data flow between them and using common language and taxonomy to establish consistency by extending dimensions between both organizational units. PMO dimensions are extended to include business capabilities and risk, while EA dimensions are extended to fully enable execution of project data and its application to applications. Alignment occurs when both functions support integrated bi-directional scenarios. EA is the role of seeing the big picture as a tool to help focus on the right details, project management. It is about architecting optimized processes and models based on leadership’s strategies for the enterprise, but a process by itself does not create value; rather, identified value requires a process. Finally, EA and PMO are often complementary disciplines in many regards, not contradictory to each other. When there is a concession to approach EA, in general, as a collaborative effort with agreement on the transition architectures, the relationship between both functions can be rewarding to the business they serve.

This article was first published in the Architecture & Governance Magazine.