Pragmatic Enterprise Architecture (2014)
Strategies to Transform Information Systems in the Era of Big Data

PART VII Cross-Discipline Capabilities

Abstract

This part represents the collection of specialty areas that are shared across all of enterprise architecture, (e.g., business architecture, information systems architecture, operations architecture, and control systems architecture), such as the standards for standards, mostly to avoid any kind of document being named a standards document when it is potentially the furthest from reality. This area can be viewed as the governance of all architectural disciplines to help ensure that the appropriate disciplines are in place and are performing to a standard that ensures an appropriate return on investment else it should be restaffed, right-sized, both, or decommissioned.

Keywords

cross discipline capabilities

innovation program

EA initiatives project management

Kanban

Scrum

Scrumban

gap remediation

AD compliance

dispute management

EA performance

resource management

standards governance

artifact governance

communications governance

global application development

staffing model

PMO

program management office

SDLC

life cycle

DIAGRAM Cross architecture discipline overview.

7.1 Cross Discipline Capabilities

Cross discipline capabilities are the collection of architectural disciplines within enterprise architecture that span business architecture, information systems architecture, control systems architecture, and operations architecture.

The business capabilities that span the architectural disciplines of enterprise architecture include the capabilities of:

- supporting an innovation program,

- project management for EA initiatives,

- detecting gaps across architectural disciplines and their remediation,

- management of application development team disputes with architectural disciplines,

- measuring performance of architectural disciplines,

- governing standards development and adoption,

- governing the development of architectural artifacts and global dissemination,

- governing global communication,

- managing finance across and within architectural disciplines, and

- providing a liaison as single point of contact between enterprise architecture and the global application development (GAD) team that supports the development needs of the enterprise architecture organization globally.

Essentially, cross-discipline capabilities are simply the shared services across the various architectural disciplines of enterprise architecture.

7.1.1 Innovation Program

The basic premise going into an innovation program is that it will facilitate a free exchange of thought as a marketplace of ideas that is equally fair to all participants. While the definition of fairness is going to vary somewhat among individuals, it should encompass a broad meaning that the overall majority of potential participants would agree with.

For example, some participants know how to communicate their thoughts effectively in an organized manner, while others clearly do not. In cases where the ability to write and express ideas may be a hindrance, the offer to extend the services of a coach or counselor may make the program fair to all potential participants.

This recognizes the simple fact that anyone can have an awesome idea, irrespective of their writing skills in general or writing skills in the language in which business is conducted within the enterprise.

Innovation programs in global companies can be structured many different ways, with different costs and returns on investment. The few that are the most effective are the ones that take full advantage of the beneficial aspects of human nature to contributing ideas.

The subtle yet important note that must always be kept in mind is that ideas must be evaluated while considering the possibility that it will not receive a fair evaluation if individuals affected by the idea are busy protecting their turf. Therefore, complete transparency of the entire process of the program can help significantly.

Although staff awareness of an innovation program may be high, typically a remarkably small percentage of individuals ever tend to participate. Among those that do participate, an even smaller percentage participate multiple times, and usually just a handful on an ongoing basis.

This, however, has much to do with the motivations of the individuals that can participate, the structure of the innovation program, and the outcomes that individuals experience when having participated. The ability to participate anonymously can also be a motivator for some.

As for motivations, there are a number of use cases that may be applicable to an innovation program.

As examples:

- an individual may simply desire to make a simple anonymous suggestion,

- an individual may simply be testing the program to see how it works prior to submitting their intended idea,

- an individual may simply want to get attention,

- a group of individuals may wish to propose a new method for performing a particular business capability,

- an individual may have an idea for a new product, or

- an individual may simply wish to create awareness of a problem that executives may be able to stumble upon if they periodically review submissions.

A good innovation program may want to support all of these use cases in an easy and simple way.

While it can be simple to design an innovation program, it is not simple to design one that is necessarily successful in achieving the objectives of management or in having a beneficial return on investment.

For example, while it may not be worthwhile for large enterprise to institute the approach adopted by Google to allocate 20% of staff time toward innovating a business idea,¹, it may prove worthwhile piloting such an approach with leads of architectural disciplines one month out of the year.

The innovation program architect collaborates with all of the subject matter experts across enterprise architecture, and perhaps most closely with life cycle architecture, workflow architecture, application architecture, and technology portfolio management.

The role of an innovation program subject matter expert requires a broad combination of knowledge and cumulative experience with human factors of stakeholders, potential outcomes of different program approaches, the various use cases of an innovation program, ontologies to support varied categories of innovations, operational workflow design, and developing proposals to present to management.

7.1.2 EA Initiatives Project Management

Project management is the discipline of planning, organizing, controlling, and motivating resources of various skills to achieve specific results involving the development or deployment of a system or application. Project management typically employs a life cycle to achieve its particular objectives, typically with a finite budget of resources within a specified amount of time.

Within enterprise architecture, the initiatives are typically of modest magnitude focused on discovery to develop a process for a larger project. Although there are numerous project management methodologies for the software development life cycle (SDLC), for small projects, the project management methodology, an increasingly common approach is Kanban and Scrumban, which is simply Kanban with Scrum-like iterations.

Kanban originated in the 1940s and 1950s with developing just in time manufacturing at Toyota in Japan. The method carefully visualizes well-defined steps of the workflow in diagrams that are reviewed by team members to help them understand how to do their work. Understanding the steps of the workflow helps management monitor progress and allows intervention to remove impediments that delay steps in the workflow. Thus, it is manageable to incorporate changes in requirements mid-stream.

In contrast, Scrum focuses on well-defined inputs and well-defined outputs for software built in sprints where the workflow cannot be defined due to complexity of the development process. Another difference is that Scrum requires management to trust the team thereby preventing interference. In Scrum, it is generally not acceptable to introduce changes in requirements mid-stream.

Both Kanban and Scrum take into consideration the fact that multitasking diminishes productivity, and equally important is the notion that switching focus is not the primary driver in diminishing productivity, but that the delay between events actually creates more work. Hence, running lean, in the context of Kanban and Scrum, is not about running fast, but instead, it is about eliminating and better managing delays by optimizing coordination among project activities and resources.

For example, a bug is much more work after it is detected 2 weeks later, and even more work after several weeks as others may have introduced changes in the interim. This requires the creation of product units that can be tested immediately, and coordination to achieve that. As such, more numerous yet smaller units are more efficient than fewer large units.

Larger project management efforts should be handled by an application development team, such as the global AD team to support the application development needs of enterprise architecture.

Other life cycles that require project management architecture, each with their own methodologies, include:

- data centric life cycle,

- data governance life cycle,

- architecture governance life cycle,

- divestiture life cycle,

- merger and acquisition life cycle,

- corporate restructuring life cycle,

- outsourcing life cycle,

- insourcing life cycle, and

- operations life cycle.

7.1.3 EA Discipline Gap Remediation

Discipline gap remediation attempts to stay abreast of the technologies being reviewed for use across the company to determine if an architectural discipline exists to properly manage that particular area is missing from the inventory of architectural disciplines or if the applicable architectural discipline currently has a subject matter expert for that discipline.

It can be possible that the architectural discipline had been previously well defined with standards and frameworks that a full-time subject matter expert isn’t required. Needs for such subject matter expertise may be available from experts on retainer or simply sent to experts on an as-needed basis.

Enterprise architecture discipline gap remediation assesses the relative cost to the company to establish an additional architectural discipline or to acquire coverage for a particular architectural discipline versus the potential cost of providing no active coverage for the particular architectural discipline.

7.1.4 AD Compliance and Dispute Management

Application development compliance and dispute management is a discipline that determines the process to address potential and actual noncompliance with standards and/or frameworks by an application development team, as well as handle application development team disputes with any of the architectural disciplines within business, information systems, control systems, and operations architecture and governance.

The process requires a method to rapidly resolve issues among the appropriate stakeholders of the standard or framework, and to promptly escalate them to management if unresolved.

7.1.5 EA Performance and Resource Measurement

Enterprise architecture performance and resource measurement collaborates with the lead of each architectural discipline to review the objectives, principles, future state, and transition plan to determine objective metrics that may be collected nonintrusively to determine the effect of architectural standards, frameworks, and governance.

The intent is to evaluate the efficacy of:

- architectural standards,

- architectural frameworks,

- governance process,

- knowledge level of the subject matter expert, and

- the subject matter expert’s ability to successfully manage the specific architectural discipline.

The role of enterprise architecture performance and resource measurement requires a broad combination of knowledge and cumulative experience in:

- application development,

- objectives, principles,

- future state,

- transition plans of each architectural discipline,

- metrics driven principles,

- nonintrusive methods of metrics collection, and

- the broad topic of metrics and measures in operational workflows and work products.

7.1.6 Architecture Standards Governance

Standards produced in isolation often do not agree with what constitutes a standard.

The results are typically the following:

- categories of content are erratic,

- actual standards are capricious,

- objectives of standards are often unclear or omitted,

- stakeholders are not identified,

- interests of stakeholders remain unrepresented, and

- adherence to standards is not uniform or nonexistent.

Modern enterprise architecture recognizes that standards must have:

- a consistent life cycle for their development with the appropriate approvals and periodic reassessments,

- stated purpose as to why the standard is necessary,

- context to facilitate an improved understanding of how the standard fits within an overall framework,

- scope to identify the boundaries of what is to be specifically included and or excluded within the standard,

- the standards themselves with their reason for being (e.g., regulatory compliance, stakeholder interest, or cost reduction) with traceability to the specifics of the reason,

- principles governing the standard in order of priority,

- intended outcomes that can be measured,

- governance to ensure compliance as well as dispute resolution,

- tools and technologies that provide automation for aspects of the standard,

- methodologies and processes that should be adhered to as part of the standard,

- ontology that facilitates classification of and easy identification of the standard,

- and notes supporting the thought process that went into the development of the standard to record the decisions that were made when each section was created.

7.1.7 Architecture Artifact Governance

Architectural diagrams and models are intended to communicate ideas and concepts efficiently and easily to various stakeholders. Produced in isolation diagrams and models are typically inconsistent and confusing often using symbols and diagramming techniques inconsistently across one another and even within the same diagram.

Modern enterprise architecture recognizes that architectural artifacts must have:

- a consistent life cycle for development with the appropriate approvals and periodic reassessments,

- types of architectural diagrams and their content,

- a proper taxonomy to name the artifact as a framework, blueprint, reference architecture, template, or guideline; templates used for commonly used diagrams and models,

- graphical symbols and colors used within diagrams,

- use of legends to illustrate the usage of graphical symbols and colors; a clear purpose,

- a depiction of the overall context to facilitate an improved understanding of how the artifact fits within an overall framework,

- scope to identify the boundaries of what is to be specifically included and or excluded,

- traceability to the specifics of the reason,

- principles governing the artifact in order of priority,

- intended outcomes that can be measured,

- governance to ensure compliance as well as dispute resolution,

- methodologies and processes used to create the artifact,

- ontology that facilitates classification of and easy identification of the artifact, and

- notes supporting the thought process that went into the development of the standard to record the decisions that were made when the artifact was created.

7.1.8 EA Communications Governance

Communications governance is responsible for developing and implementing a process by which all communications from enterprise architecture will be developed, approved, disseminated, and recorded, including the measurement of feedback.

The standards for communications governance should be leveraged by every architectural discipline, especially the discipline responsible for standards governance.

For example, the use of simple language is required using basic grammatical structure, such that the use of complex or lengthy sentences, metaphors, or colloquialisms should not be permitted in standard documents.

7.1.9 EA Finance

The typical enterprise architecture organization is unusually weak with respect to their financial skills. Some may believe that this may be because EA budgets are so small to begin with, or that there their budgets are often treated as management overhead to the organization. Often, EA staff members do not even have to participate in time accounting. This, however, is not a good idea. Accountability begins with time accounting, so management can simply determine where time and effort was spent.

In a modern enterprise architecture department finance is responsible for the standards and frameworks by which each architectural discipline must plan and manage financial resources and financial reporting, with finance being one of many essential metrics.

7.1.10 GAD Team Liaison

Enterprise architecture has reoccurring needs for application development capabilities, including the ability to eventually migrate applications and technologies into production. To accomplish this, there are two basic approaches to consider.

7.1.10.1 Internal Application Development

The first option is to create an application development team within the enterprise architecture organization. The benefit of this approach is that a dedicated team will be more responsive and more specialized.

7.1.10.2 External Application Development

The second option is that a large enterprise should have a GAD team that supports development needs that span all regions and countries. The benefit of this approach is that there are likely to be core business capabilities that a GAD team would develop by consolidating multiple application systems into.

Since application consolidation is no simple matter, a GAD team requires a higher level of skills than most application development teams, and this meets the needs of enterprise architecture and its architectural disciples extremely well.

The GAD team liaison provides a single point of contact for coordination, planning, and reporting of application development support needs of enterprise architecture with the global development team of the company.

The role of GAD team liaison requires a broad combination of knowledge and cumulative experience in project management, and the current and near term development needs of enterprise architecture.

7.1.11 Architecture Staffing Model

There is a saying in sports that good coaches play the team they have rather than the team they want. IT organizations, including EA, have the same problem. They must be willing to honestly assess their capabilities and make adjustments. Few organizations are “world class” regardless of what their C-suite says (in fact by definition some of them must be among the worst—by whatever yardstick is used).

Simply put, this means that not all organizations are capable of performing all tasks that they dream up. I can imagine winning a Stanley Cup, but do not have the talent to do so.

The number of architectural disciplines necessary to properly manage the automation efforts of a given company can vary significantly depending upon the complexity that has resulted from numerous:

- acquisitions and mergers,

- business lines,

- data centers,

- computing platforms,

- product lines,

- applications,

- technologies,

- databases, and

- IT management.

In general, though, it is fair to say that the number of architectural disciplines in a large enterprise that does not develop control systems is likely to range between 50 and 80, sometimes more, sometimes less. Adding into that the disciplines required to support control systems and it roughly doubles.

When it comes to staffing architectural disciplines, some subject matter experts can cover just one architectural discipline, while others can handle a collection of them. At that point, it is somewhat more a factor of the number of concurrent initiatives that they may be required to support.

Once a company determines the set of architectural disciplines appropriate to control and direct the architectural decision making across the globe, it is time to illustrate the potential staffing levels and organizational structure of resources to deliver these services in a global operating model.

From experience, the process of identifying the candidates that are suitable to lead each architectural discipline is a long and arduous one, although with great rewards once the right team has been developed. Depending upon the background of the individuals, some candidates can easily lead multiple architectural disciplines, whereas some individual disciplines are extremely difficult to staff.

For the most part, educational institutions and vendors do not yet offer studies in most architectural disciplines of enterprise architecture. Therefore, the approach we recommend is simply the approach we used, which is to review large numbers of resumes of senior consultants, interview 1 of 50 by telephone, out of those bring in 1 of 5 for an in-person interview with your team, and onboard 1 of 3 as a consultant.

Once onboarding has been completed, the assessment period to determine if the candidate can appropriately lead the architectural discipline begins. If we are successful in mentoring the individual to appropriately lead the architectural discipline, then we may offer the consultant a senior role to convert to an employee of the enterprise, or potentially provide a part-time consulting position to them eventually to reduce the costs of having full-time coverage for a few of the less active and or demanding architectural disciplines.

I should note that over an 18-month period, we had to onboard a third candidate a handful of times, and in a couple of situations, we had to onboard a fourth candidate until a suitable subject matter expert could be identified.

By starting with consultants, it easily avoids the problem of hiring full-time employees only to find out shortly after they start that they cannot do the job they were hired to perform. If hired as employees from the start, to terminate and replace them could take the remainder of your career—potentially a deservedly short one.

We found that a few requirements were standard across all architectural disciplines, such as:

- Candidate must be able to articulate the pertinent principles that guide their architectural discipline to executives in business and IT, including to other architects to guide the activities of IT to be in alignment

- Candidate must be able to support the informational needs of business and IT, including architects and application development teams in a mentoring style

- Candidate must be an effective communicator in business and IT at all levels of the organization

- Candidate must be results oriented

- Candidate must consistently demonstrate initiative, constructively engage, and be a strong advocate of the business across IT

The mindset of architectural leads can have a significant effect on their ability to properly protect the interests of the business. It is therefore valuable for subject matter expert to understand the effects of dealing with other staff members, especially when they have multiple degrees of separation from the business, and business concepts.

7.1.12 EA Relative the Program Management Office

The primary goal of the program management office (PMO) is to standardize project management processes, policies, methods, and reporting guidelines. Over time, the PMO can provide guidance, documentation, examples, and metrics for managing projects. The PMO will commonly oversee project management and report project management status back to executive management.

The effectiveness of the PMO is typically determined by how well it is staffed and the experience level of the staff. Many large organizations recognize the need for a strong PMO, but fail to position it so that it can deliver the type of value that it is actually capable of delivering.

Although there are often a variety of challenges that a PMO faces in order to become effective, perhaps the most significant is that it is typically only aware of a SDLC and its associated steps, standards, and documentation. This positions the PMO to perform the role of project management oversight with one lens.

In an analogy with a professional photographer, this would limit the photographer to taking photos well when the subject of the photo is just the right distance away under only one ideal type of lighting condition.

One of the most advantageous organizational alignments that we have seen in successful organizations is to include within the organizational structure of enterprise architecture. This alignment allows EA to determine the appropriate set of life cycles for the PMO to become proficient in and causes project management alignment with the right architectural standards for the appropriate life cycle.

To continue the analogy, this would allow the photographer to take professional photographs at a variety of distances under a variety of lighting conditions, day or night, in any direction from the light source, for any distance.

It is important to note that the benefits of this organizational alignment work in the reverse direction as well. When the PMO encounters issues with certain types of life cycles, steps, standards, or documentation, they are now as close as they can be to ideal source to collaborate with to remedy the problem or take advantage of the opportunity.