The highest of four (4 of 4) levels used to Organize People for Iterative Transformation includes roles with the broadest perspectives on change.  For instance, looking to the ITMs objective of sharing architectural knowledge, at this level one of the key roles is an Enterprise Architect. In effect, these roles look across the organization. Moreover, they should seek to provide the best possible Solutions to support an organization's overall strategy and objectives.
Previously, lower levels introduced Team Level roles, as well as roles appropriate for specific, single Solutions and general, or multiple Solutions. Accordingly, at each level the focus was upon a single Solution or set of Solutions. At this time, these roles look at change from an enterprise perspective. Looking across all Solution, or the Solution Portfolio, this level sets overall guidelines and objectives, providing transformational direction.
This level introduces the following Roles:
- Epic Owner
- Enterprise Architect
- Key Business Stakeholders
- Key IT Stakeholders
For a quick summary of Roles & Responsibilities associated with Iterative Transformation, refer to the Solution Delivery RACI.
Porfolio Level Roles
The following roles identify individuals who set overall strategy and define organizational objectives. Solutions must strive to work within the established guidelines.
Epic Owners
In general, an Epic defines some large, broad area of functionality owned by one Business Segment. For instance, from a Product perspective, think along the scale of 'Sales', or 'Sales - North America', or perhaps 'Opportunity Management'. Alternatively, from a System perspective, think along the lines of 'Collaboration', 'Integration' or 'Analytics'. Overall, an Epic Owner (EO) is the individual accountable for the prescribed business function. Given that, Epic Owners have two separate, but related aspects to their role.
Firstly, during Portfolio Management when a new, un- or ill-defined Portfolio Epic begins to take shape. At this time, an Epic Owner will help define Solution objectives. In this case, the Epic Owner is accountable for guiding the Portfolio Epic through its initial definition. This continues until the initial Portfolio Epic becomes one or more specific Solution Epics.
Secondly, after the Solution Epic is defined the Epic Owner identifies Business and/or Process Owner(s). These individuals will fulfill their role in the delivery of the corresponding Product, System or Service. Moreover, Epic Owners may also participate in defining Features and Capabilities which relate to their Epic.
In both cases, an Epic Owner sets or approves a Solution's objectives for their Business Segment. Further, they retain accountability for ensuring that delivered Solution functionality achieves such objectives. Of course, given their position in the organization, each Epic Owner must set organizational objectives in collaboration with their peers.
Moreover, Epic Owners may also determine cost estimates and secure funding for work related to their Epic. In this case, they play a significant role in how much, and how quickly, change can occur. For instance, the available budget directly affects the size and number of Teams available to work on related change.
For additional information see:Â Scaled Agile Framework - Epic Owners.
Enterprise Architect
On the one hand, Epic Owners represent the business, its needs, and objectives. Even when a System will be owned by IT, its Epic Owner(s) still looks to enable business objectives and strategy.
On the other hand, an Enterprise Architect (EA) (ER in the diagram) is responsible for the organization's overall technology strategy and roadmap. That is, an Enterprise Architect's goal is to ensure the proper applications (Products) and technologies (Systems) are available to support the business' strategic needs and growth objectives.
In effect, most Enterprise Architects work across Value Streams and/or IT Services, helping to design them. Accordingly, they should play a key role in the selection of any new application or technology, as well as their use. Moreover, they may participate in defining Solution Visions.
In fact, an important aspect of implementing IT strategy, and the architectural roadmap, is the objective to drive greater enterprise value. For instance, through lowering costs and increasing benefits. Proper selection and use of individual Solutions are the building blocks for driving such value.
Accordingly, Enterprise Architects communicate strategic themes to Solution Architects, as well as to Product-, System-, Service-Architects. Ideally, this will ensure individual Solutions align with broader IT Strategy and overall Enterprise Architecture. Moreover, an Enterprise Architect will review Solution Strategy & Architecture materials produced by Solution Architects. Above all, they help guide individual Solutions towards achieving both business and technology objectives.
Finally, Enterprise Architects also establish design and infrastructure standards across Solutions to speed and simplify their architectural aspects. For instance, the should strive for the reuse of Operational Tools, such as those used for Work Management and Solution Collaboration. As a result, they help build a technical foundation which enables all business Epics.
For additional information see:Â Scaled Agile Framework - Enterprise Architect.
Key Business Stakeholders
The list of Key Business Stakeholders will vary from company to company. In general, it refers to individuals and groups having an interest in, and influence over, changes to the organization's IT portfolio.
For instance, individuals include C-level executives, as well as any senior leadership to whom an Epic Owner may report. Alternatively, groups may include a finance committee, governance board, or similar entity. Generally, such groups may affect the planning and operation of the portfolio, as well as any major changes made to it. Similarly, peers to Epic Owners who may be affected by proposed changes may also fit into this set of stakeholders.
Regardless, these stakeholders have influence, and in many cases authority, to affect transformative change. For larger initiatives, it is likely these stakeholders will play a direct role in some aspect of change. For other initiatives, it is a good idea to keep these stakeholders informed of ongoing changes.
Key IT Stakeholders
Key IT Stakeholders typically include senior IT leadership. Again, "key" refers to individuals and groups having both an interest in, and influence over, changes to the overall portfolio.
For instance, individual roles include the CISO/CSO as well as the heads of IT or shared service areas. For instance, a Transformation Management Office (TMO), Program Management Office (PMO), Enterprise Applications, Infrastructure and so on. Alternatively, groups may include an Architecture Review Board (ARB), of which the Enterprise Architect would be a leader. Or, perhaps a budget committee, or other such assembly to help to establish and conform to IT strategy.
As with Key Business Stakeholders, these stakeholders have influence, and often authority, to affect transformative change. As a result, their involvement is likely with larger initiatives. It is a good idea to inform them of all proposed and ongoing changes.
Finally, this concludes the ITM section on How to Organize for Iterative Transformation. The next section to cover depends upon the area of interest:
- Portfolio Management Processes - for the broadest perspective of Iterative Transformation, including Solution Definition and the first steps towards Solution Delivery.
- Business Process Definitions - to capture and define what Business would like to achieve with Iterative Transformation.
- Solution Strategy & Architecture - to define individual Solutions and the objectives to achieve over long-term increments.
- Analysis & Design - for the work which follows Portfolio Management and Defining Business Processes and gets Solution Delivery under way.