Architect Lifecycle Engagement Assessment & Integration

Most organizations have existing lifecycles with relation to strategic and business planning, project lifecycle, service management and various others. Iasa has found that the most effective manner to introduce an Architect engagement model is through a non-invasive non-threatening manner. The engagement effort should be sensitive to the organization’s culture, technology posture and current state attitude with relation to architecture and IT in general.

Step 1: Identify Organization Lifecycles

The goal of this assessment is to understand the heartbeat of the organization. Governance structures such as boards, committees, internal power structures, budgetary and financial alignment form part of what is captured. This is also an opportunity to explore the operating model of the organization as this information is key to understanding what form a connected architect organization should take.

Time & Timing

Time and timing is a key factor to record as a part of this analysis.

• When does strategic planning happen? E.g. annual, bi-annual
• Do intermediate strategic alignment meetings occur?
• When are business plans developed?
• When are business plans funded?
• When do key boards meet?
• Is there a stable timeline between request/opportunity identification and go-decision?

Step 2: Identify existing architecture engagement points

In this step existing engagement points are identified. Typically in low maturity organizations this will be consist of either no architecture, architect is senior developer (software projects), architect review occurs with no enforcement (box-ticking). The key goal in this step is to gather existing role definitions for ‘architects’ and architecture related activities.

Step 3: Identify areas to strengthen

Where existing engagement touch-points exist the goal is to maximize the effectiveness of the engagement. For example if an Architect Review Board (ARB) exists in incubation mode the advice is to clarify/solidify the role, decision-making authority and value proposition. In conjunction with any strengthening, a communication exercise should be undertaken to describe the change along with associate value statements.

Step 4: Identify new engagement opportunities

Step 4 involves seeking to expand the reach of architecture engagement into areas that will demonstrate the value of architect involvement. Examples of this in low maturity organizations include involvement in strategic & business planning. Innovation management and opportunity identification are another area, which warrants attention.

Health Warning

Extending the engagement model is fraught with risk as other roles sense the beginning of the architect capability expanding into their areas of responsibility.

Approach 1: Partnership

The partnership approach ensures that there is a win-win scenario described for all stakeholders’ e.g. existing roles, customers, executive management will all benefit. In order to effectively take this approach the architect team must be able to clearly articulate to others what the need is and how an architect on-board will help e.g. technical debt typically arises as a result of poor/no architecture evaluation and decision-making. The costs are typically not incurred within the project lifecycle but are felt later once the system/solution is in service management or requires change. Technical debt will ultimately affect anticipated benefits. Positioning architects as being responsible for these decisions off-loads responsibility from other roles.

Leveraging existing relationships is key to success. Identifying colleagues from other roles who already see the benefits or informally use architects and empowering them to market the benefits will reduce barriers to change.

Approach 2: Power

The consensus approach is preferred as a change mechanism as it incurs the most benefits with the least downsides. However in organizations unwilling to allow architect engagement to occur in strategically important areas then using a source of formal power e.g. C-level executive to either make the change or back the change will be required in most occasions.

Health Warning

Using formal power to force the change can have negative effects as other roles are more likely to protect/defend existing relationships. This can manifest itself in a number of ways avoid, ignore, maliciously comply.

Approach 3: Fear

As with Power this approach should be used carefully, the areas of enterprise risk and technical debt can be used to create a ‘fear’ that other roles will seek to offload onto architects.

Health Warning

The negative to this approach is that architects will be seen in a compliance and risk avoidance role rather than as an innovation engine.

Approach 4: Stealth

Finally when all else fails ‘better to beg forgiveness than ask permission’ this approach involves making architecture engagement happen in key areas and quickly demonstrating value from that engagement. The change becomes the new norm and official process guidance will typically lag behind.  This approach requires expert level human dynamic skills in order to be effectively executed.

Step 5: Create value statements for each engagement touch point

A key question that organizations ask time and again at low levels of maturity is ‘what does that architect do?’ Architects are seen as a cost to the organization and although they are often seen as necessary it is unclear as to the specific value they deliver.

Each architect engagement touch-point MUST have a related value statement that becomes the architect team’s engagement mantra.