Nick Malik wrote a great post titled The Rule of EA Governance that hits to the core of EA and IT governance. It is a must read and I highly recommend it. Nick asserts that:
All Enterprise Architecture will be implemented according to the structure of ownership and governance that exists in the enterprise.
Next Nick explains why this is important by using an example of a CRM implementation in an organization. He specifically states that:
If you have two business customers who both want a CRM solution, and you have one governance body, you will end up with one CRM system. If you have two governance bodies, you will end up with two CRM systems. If you have four business units who want CRM, and you have three governance bodies, you will end up with three CRM systems.
This rule plays out repeatedly. I’ve never seen it fail.
The failure to recognize “The Rule of EA Governance” is one of the causes for the failure of an EA program.
I too have seen this throughout my career and my work with multiple organizations to introduce enterprise architecture practices. We have seen many reports and stories about how EA programs have failed and I completely agree that a lack of ownership and governance contributed to the failure.
Now I want to suggest a practical approach to help your EA practice make “The Rule of EA Governance” tangible. Build an application/service portfolio and ensure that you associate an Executive Sponsor and a Business Owner to each item in the portfolio.
Once you have done this, start showing it to people … it is amazing when people see their names or their departments associated to a particular thing how interested they get! Nick had a good quote:
The business doesn’t care about nice drawings and great designs. They care about “stuff they own” and “stuff they don’t own.”
If people never see what they own, how can we expect them to govern usage especially when it is a shared service? Nick ended with an approach to help all of us move our Enterprise Architecture practices forward:
So if you want to know if your Enterprise Architecture can be implemented, count the “things” in it. Then count the number of those things with exactly one owner (and clear governance). Those are the things that will be implemented just the way you describe it. Everything else is a free for all.
Simple and brilliant – thanks Nick!
To help you get started with your application portfolio, I provided a list of sample attributes in our Application Portfolio (see below). We used an Excel workbook to capture the attributes for our Application/Service Portfolio. As we gathered data, we needed a way to do some analysis, so we migrated the data to an MS Access db.
Good luck and hopefully with Nick’s approach and my suggested implementation of an application portfolio, you can find an enterprise architecture can be successfully implemented.
| Application Portfolio DefinitionsDescription | |
|---|---|
| Application/Service | The service that accomplishes a logical unit of work. Made up of Core, System, Application and Business software. |
| Executive Sponsor | The Vice President who has governance responsibility to deliver services that this application supports |
| Business Owner | The Dean/Director/Manager who has line management responsibility to deliver services that this application supports |
| Technical Manager | The IT Services AD/Manager who has line management responsibility to ensure the application is available to support the business service |
| Technical Owner | The IT Services Analyst who has direct responsibility to ensure the application is available to support the business service |
| Technology Management Definitions | see below |
| Technology Lifecycle Definitions | see below |
| Service Level Agreement (SLA) | The application has a service level agreement in place via a direct SLA, in the IT Services Core Service Catalogue or none |
| Application Type | see below |
| Implementation Year | This is the year the application was implemented in |
| Application Service Provider | The application is externally hosted by an application service provider (yes, no) |
| Web Enabled | The presentation of this application is primarily in a web browser and relies on Internet technologies (yes, no) |
| Authentication | The application requires an id and password before a client is allowed to access it. (yes, no) |
| Authorization | The application contains security that authorizes (usually role based) an authenticated client to access certain data or forms. (yes, no) |
| Identity Source | This is the place the application goes to find authentication and authorization information and may be internal or external to the application |
| Web Server | This is part of an N tier architecture and refers specifically to the server that runs the web server. |
| Web Server OS | This is the operating system that runs on the web server |
| Application Server | This is part of an N tier architecture and refers specifically to the server that runs the application |
| App Server OS | This is the operating system that runs on the application server |
| Data Server | This is part of an N tier architecture and refers specifically to the server the hosts the data (structured/unstructured) for an application |
| Data Server OS | This is the operating system that runs on the data server |
| Application Development Env | This is the application development environment that the application is created in |
| Storage | This defines where the disk storage for the application resides (local, SAN-Fibre, SAN-SATA, ASP) |
| High Availability | This application has infrastructure in place to make it highly available (24×7) (yes, no) |
| Test Environment | This application has an existing test environment (yes, no) |
| Depends on (Upstream Application) | This application’s logical unit of work depends on another application’s logical unit of work. |
| Supports (Downstream Application) | This application’s logical unit of work supports another application’s ability to accomplish a logical unit of work |
| Vendor | This is the Vendor that supplies the application software |
| Technology Management DefinitionsDescription | |
|---|---|
| Enterprise | Represents the planned, budgeted and fully supported technical infrastructure for both academic and administrative systems at BCIT. Service levels are defined. IT Services has complete responsibility for funding, control and support. EA has an approval role. |
| Shared | Represents the planned, budgeted and fully supported technical infrastructure for both academic and administrative systems at BCIT. Service levels are defined. IT Services shares responsibility for funding, control and support with a department to deliver a shared service. EA has an approval role. |
| Departmental | Represents those installations unique to a school or department for which IT Services has made special support arrangements. They are not enterprise as they do not serve common needs across the institute. They are not necessarily innovative as they represent core systems within a department. IT Services has joint responsibility based on Service Level Agreements. EA has an approval and consulting role. |
| Innovative | Represents initiatives related to research and investigation of new and evolving technologies. Service levels are defined in consultation with IT Services. Service levels may be lower than those provided in the mainstream, base funding in the short term may not be available, IT Services acts in a consultative and partner role. Activities may move into the Enterprise if they have proven, long-term benefits. EA has a consulting role. |
| Opportunistic | Represents activities that are unanticipated yet they closely align with the strategic plan of the Institute. No support services are available. Funding for technology, infrastructure, software, expertise, technical support and instructional support etc, is provided through external means (i.e. grants, external contracts etc). EA has a consulting or guidance role. |
| Technology Lifecycle DefinitionsDescription | |
|---|---|
| Watching (W) | includes initiatives and technologies that are being watched for maturity in industry. An initiative that falls into this category may, upon positive evaluation, move into the Researching portion of the cycle. Technologies mentioned in this portion of the life cycle are strictly being watched and not ready for researching yet. |
| Research and Development (R): | includes initiatives and technologies that are currently under consideration, investigation, or evaluation for future implementation. An initiative that falls into this category may, upon positive evaluation, move into the investing portion of the cycle. Technologies mentioned in this portion of the life cycle should be used only for pre-approved, proof-of-concept projects. An initiative that is in the Research and Development phase is not appropriate for wide dissemination or large-scale implementation. No modifications to existing systems or initiatives that are in the Sustaining or Containing portion of the cycle should be made for Technologies in this phase. This phase may add components to the Enterprise Architecture. |
| Investing (I): | includes initiatives and technologies that are the target of resources including financial investments and/or investments of human resources. Initiatives in this portion of the cycle are being actively executed. Technologies that are in the investing phase are recommended for wide-spread deployment across the institution. Technologies in the Investing portion of the cycle are good candidates to replace Containing or End of Life technologies. Modifications to existing systems or initiatives that are in the Containing portion of the cycle may be reviewed and considered for new initiatives in the research and development phase. |
| Sustaining (S): | includes initiatives and technologies that deliver services identified in the Core Services Catalogue or in Service Level Agreements. Typically these include technologies and initiatives that have been successfully implemented and completed, that have entered a sustainment/maintenance phase. New investments in the Sustaining phase ensure the initiative or technology continues provide service to the organization. Existing technologies may continue to rely upon these components as well as extend existing implementations. Technologies in this phase of the cycle must be maintained to ensure service delivery. Modifications to Sustainment implementations may be reviewed and considered for initiatives or technologies in the Research and Development or Investing phases. |
| Containing (C): | includes initiatives that have been completed and technologies that are in the process of being phased out. This includes technologies and initiatives that are being replaced by new technologies or processes. Technologies that have no vendor, community or industry support should also be included in this category. Technologies and initiatives in the Containing phase should have a clearly defined phase out plan. Any technology in the Containing phase that is core to the strategic goals and objectives of the institution should have replacements in place in either the Research and Development or Investing phase of the cycle. |
| End of Life (E) | includes initiatives and Technologies that are retired from service due to a lack of need for the service, upgraded/newer technology or a change in strategic direction making the initiative or technology redundant. This phase removes components from the Enterprise Architecture. |
| Application TypesDescription | |
|---|---|
| Business Application | Those applications that perform a business function. Examples would be Student Registration, eLearning, Timetabling System, etc. |
| a: Custom Written – written in house | |
| b: Custom/COTS-COTS package that would take over 30 days to customize. (COTS – Commercial Off the Shelf) | |
| c: Custom/Outside Source-Run by an outside source | |
| d: COTS-COTS that would take less than 30 days to customize. | |
| System Applications | Those applications that support the processing of Business Applications. Examples would be Linux, AIX, Windows Server, Monitoring tools. |
| a: Infrastructure Software | |
| b: Operating System | |
| c: System Support Tool | |
| Development Applications | Those applications that assist programmers in developing the business applications. Examples: Oracle Forms, Java, PHP, PL/SQL. |
| a. System Development Tool | |
| Core Applications | Those applications common to the enterprise and support the everyday functions of the enterprise. Examples would be MS Word, MS Outlook, Adobe Acrobat, Host on Demand, Internet Explorer, etc. |
| a. Workflow | |
| b. Email |