Although its benefits are well known, enterprise architecture (EA) and its use is not always an easy sell. All too often, efforts to establish an EA program are met with resistance or, due to previous unremarkable EA efforts, are not initiated in the first place. This is due to overselling the concept and underselling its effort. The negative results occurring from these are exacerbated by improper implementations of both the EA concept and process. Incompetent implementations result in products, results, and recommendations that may or may not be correct, but are out-of-date, unwieldy, out of sync with the enterprise, and generally of little or no use to the relevant stakeholders.
Overselling the concept, underselling the effort, and improper application in no way diminish the potential effectiveness of EA initiatives, but they can result in it becoming a “four-letter word” within the organization. When this occurs, the EA efforts and activities can still be executed, but they have to be implemented as “stealth EA” efforts and activities. The enterprise architects (or equivalent staff) within the organization are still developing “as-is” models, developing “to-be” models, performing gap analysis, and engaging in everything else that would be expected to be in the EA Life Cycle (EALC). High-level descriptions of the EALC include pre-cycle/”setup” activities (identify relevant stakeholders, establish governance processes, select methodologies and tools, and so on) and an ongoing set of cyclical activities. Cyclical activities include:
- Develop current EA.
- Develop target EA.
- Perform gap analysis.
- Produce phased implementation plan(s).
- Use the EA (perform phased implementation).
- Maintain the EA (review progress metrics)
Because everything being performed as stealth EA ties in to everything that is expected as EA activities, linkages are provided as expected that essentially create a localized EA (as if you were taking the “urban renewal” EA approach). The end result can be a successful EA effort that is not labeled as such, one that establishes trust and success among the stakeholders and may result in more widespread future adoption of the EA methodology across the relevant stakeholders within the organization.
ACHIEVING EA RESULTS IN “STEALTH MODE”
If the problems associated with EA are related to high visibility past projects, either at the organization or in some other context, there will be resistance to adopting EA efforts at the organization. This resistance can be overcome by performing the same activities as if it were part of an existing EA infrastructure within the organization, achieving the same successful results, collecting the same metrics of performance, and otherwise behaving as though it were a localized EA effort, but calling it something other than EA.
A STEALTH MODE CASE STUDY
John Zachman, the “father of EA,” has stated repeatedly “the application is the enterprise.” In other words, in many instances an application architecture is a microcosm of the corresponding EA for the enterprise. If the application is an enterprise-level application, the application is even more aligned to the underlying EA for the organization. The application architecture for an enterprise application aligns to the strategic and business architecture, the data architecture, and the technology architecture of the organization. These architectures may or may not be documented, understood, aligned, or well maintained or governed.
As an example, an organization is chartered with tracking a certain type of application, both logically in processing the application and physically in knowing where the application form currently resides. The application is paper-based, but the process is at least partially automated and electronic. The organization’s current system was rife with problems, such as being built using outdated technologies, relying on fragile infrastructure, and violating multiple security protocols. The solution that should have been processing applications with minimal backlog had at the time an average backlog of approximately eighteen to twenty-four months.
The strategic architecture of the organization was well understood and well documented. The processes surrounding the application process were well understood by the line staff responsible for ensuring the applications resulted in reasonable decisions based on the information supplied by the applicants. The data architecture was well understood but partially siloed from the rest of the organization. There were “shadow databases” that were snapshots of the operational database to perform processing not supported by the operational system. The technical architecture was well understood and partially siloed from the rest of the organization, resulting in multiple sets of technical standards.
The client organization required a solution that would integrate within the organization, align with the strategic architecture, define and govern the data and technical architectures in alignment with the rest of the organization, and define and govern a multi-tiered, secure, extensible, data-driven, multi-platform application architecture. In short, the optimal long-term solution included the basis for an EA within the organization. The solution was provided on time, on budget, and provided the basis for EA activities for the organization.
The effort began with a feasibility study, identifying all reasonable options with their associated costs. The feasibility study included as part of its evaluation criteria the establishment, alignment, and integration of the architectures defined by the solution with the other areas of the existing organization. During the feasibility study, the relevant stakeholders were identified, and a set of governance criteria for the development of the solution was established.
Following the feasibility study, processes were defined and validated by the relevant stakeholders identified as the owners of the processes. The primary customer within the organization expected this effort to take four times as long as was actually required. The processes were mapped and maintained according to a set of governance procedures, and were used to re-engineer the processes to initially reduce the backlog of applications. The mapped processes were also used by the process owners as training materials to reduce onboarding times for both new employees as well as cross-trained line staff.
The validated processes were mapped to the strategic architecture, establishing evidence of full support of the mission, visions, goals, and objectives at the process level. The processes were then used to define a comprehensive set of use cases from which the system design was constructed. The system was built as a service-oriented, data-driven, role-based, multi-tiered solution. The services layer was used as the basis for other applications after deployment of the initial solution.
The data architecture was designed to support the development of a master data model (later implemented as part of the data tier of the solution within the organization). As a result, siloed data was phased out significantly. The technical architecture for the solution was designed to support multiple offices within the organization, reduce redundant technologies, and improve economies of scale. These were all accomplished, improving the bottom line of the organization.
When the solution was completed and accepted, the solution defined a set of interdependent, aligned architectures with governance processes that resemble a fullscale EA. Within six months of implementation, the backlog of applications was decreased to essentially zero. The result was a scalable, extensible, secure solution used as the foundation for future enterprise applications. The result was an EA implementation that established an EA framework, provided the benefits of a successful EA implementation, institutionalized the governance processes, and established an EA culture, also in “stealth mode.”
In summary, EA is a process that has value enough to be implemented as part of any significant effort within an organization. Once its successes are demonstrated, it is of minimal importance as to what it is called, but it is important that it become part of the culture of the organization. Once that is accomplished, stealth EA efforts are every bit as valuable as a “named EA” effort.
