The Enterprise Administration Discipline: Scaling Agile Software Development

	The Enterprise Administration Discipline: Scaling Agile Software Development
Home \| Contact Us \| Licensing \| Announcements \| Downloads \| Site Map

The Enterprise Administration discipline extends iterative/agile processes such as the Rational Unified Process (RUP), Extreme Programming (XP), or Scrum to define how an organization creates, maintains, manages, and deploys physical and informational assets in a secure manner. The goal is not to simply add a new level of bureaucracy, but rather to streamline these activities: it is easy to see how a bureaucracy could be formed within your organization as you read this article, but as always my advice is to remain as agile as your situation permits. Some people look at enterprise administration as an extension of the Operations and Support discipline, but we separate it because its activities cross almost every discipline within the Enterprise Unified Process^TM (EUP). In particular, this is a fundamental aspect of the advice provided by the Information Technology Infrastructure Library (ITIL). Like any phase or discipline within the EUP, different organizations will apply the activities contained within this discipline in different ways. Do what makes sense in your environment. It is important to note that enterprise administration is one aspect of enterprise discipline, a critical scaling factors for ensuring that agile approaches scale to meet the needs of your full IT organization.

Overview
Managing physical assets
Managing information assets
Managing security
Supporting project teams
Summary
Translations

1. Overview

There are five roles in this discipline, one abstract and four concrete:

Enterprise administrator. Enterprise administrators are actively involved in managing physical and informational assets along with security and working with project teams. The other four roles in this discipline all inherit from this one.
Network administrator. This role is responsible for managing and supporting the hardware and network for the organization.
Facilities administrator. Facilities (such as buildings, new construction, and undeveloped land) for the organization are managed by this role.
Information administrator. This role is responsible for managing the information assets of your organization, including data, intellectual property (IP), and licenses.
Security administrator. This role is accountable for physical and informational technology (IT) security.

The high-level workflow for the Enterprise Administration discipline is depicted in Figure 1 and the detailed amalgamated workflow in Figure 2. This discipline includes the management of physical assets, information assets, and security for the enterprise. One of the most important activities within this discipline is working effectively with the project teams to support their efforts while ensuring that the long-term needs of your organization are still met. An important message of this discipline is that in order for it to succeed your organization must be as agile as possible: it is possible for enterprise-level professionals to work in an agile manner, but they must choose to do so and be allowed to do so.

Figure 1. The workflow of the Enterprise Administration discipline.

Figure 2. The amalgamated workflow of the Enterprise Administration discipline.

2. Managing Physical Assets

The physical assets within your organization include hardware, networks, and your computing facilities. The network administrator is responsible for managing both hardware and networking infrastructures within your organization. This person, if he or she is not someone from the operations and support staff, works closely with these people at all times. The network administrator must keep both the hardware and network plans up-to-date and ensure that information is available and communicated to the various project teams. Network administrators follow the relevant network and hardware guidance to ensure that their work reflects the long-term vision captured within your enterprise architecture model.

Network administrators are involved during the initial stages of a project to help get the team set up with the appropriate hardware, software, and network infrastructure. They will be called upon throughout the Construction phase to help the project team with issues such as networking and infrastructure support and establishing a test environment in parallel with a production environment. At the end of the Transition phase, network administrators are involved to ensure smooth deployment into your production environment. During the Production phase, they help the operations and support staff with any monitoring situations that arise. Finally, when a system is retired, network administrators are heavily involved in sunsetting aspects of the system which affect the network.

Facilities administrators are responsible for the computing facilities of the organization, including telecom and network infrastructure creation and maintenance (outside of the IT world, this can also include buildings or undeveloped land). Much like the network administrator, this person is tertiary, working with the project teams throughout all phases, including the Production phase, and helping with any operations and support-monitoring situations.

3. Managing Information Assets

The information administrator is responsible for managing the information assets (the data, intellectual property, and licenses) of your organization. Figure 3 depicts the management activities for information assets. The information administrator must deal with the following goals:

Data stewardship. The goal of data stewardship is to ensure that responsibility, accountability, and authority are associated with auditing and reviewing the quality of data.
Effective metadata management. Process solutions should be considered in information-rich industries, which are especially prone to experiencing metadata-related pain. Metadata repositories generally support both technical and business aspects. Technical metadata is generally for the IT staff and users; business metadata is used by business users within an organization. Also, contrary to popular opinion, you can in fact take an agile approach to Master Data Management (MDM)
Data storage build out. Your enterprise architecture model defines, among other things, the data architecture within your organization including your forecasted data storage needs. Information administrators must ensure that the data storage infrastructure is upgraded in a timely manner to meet these needs.
Support both online transaction processing (OLTP) and business intelligent/data warehousing. Information administrators should work with the specific project teams to support both approaches.
Information quality. Quality of information is a subjective term, and measuring quality is even more onerous. Information valuation is at best misunderstood and at worst an extremely flawed academic exercise. The different types of data stewards (definers, creators, and readers) are responsible for maintaining quality of the information, and because they have different goals, they will provide checks and balances within your environment. The information administrator should work with the project teams to educate them about data quality concepts; these can include concepts such as data types and complexities, data integrity, the usage of keys, how to avoid duplicate rows, normalization, data hierarchies, redundancy, and metadata.

Figure 3. Manage enterprise information assets workflow details.

The information administrator is responsible for managing the data within the enterprise. This person is normally involved during all phases. The need for flexibility with project teams here is paramount: the team will need leeway to try different things. The information administrator must ensure that before a system goes into production, all of the information assets are correctly defined and in place, including ensuring that licensing is completed. Effective information administrators recognize that:

Data is one of many enterprise assets. Although some people within your organization may claim to "own" all of the data, in reality many people have input into this vital enterprise asset. You must work with the project teams to make this point clear. In the Zachman Framework, enterprise data maps into the What (Structure) column of the framework.
Data is only one of many important aspects of an application. Too many organizations allow the data tail to wag the application development dog. The reality is that data is one of many important issues (this is the first philosophy of the Agile Data method), and it often isn't the primary one (regardless of what data professionals may think).
Some data will be inconsistent. Ideally data should be consistent and should be stored in one place only. Realistically, that's not going to happen; however, this should be one of your primary goals.
You need to make trade-offs. Sometimes you need to sacrifice long-term investment in your data for the sake of the short-term need of development teams. Ineffective information administrators will focus solely on the data, insisting that data issues are completely thought through early in a project, a serial approach that ignores the fact that EUP development teams work in an evolutionary manner. Information administrators should work closely with project teams to learn the team's specific needs and requirements as well as to communicate enterprise realities to the teams and the develop a plan that works for both.
You must be flexible. Bureaucracy breeds inflexibility. If the information administrator is handing down orders and ideas in a one-way fashion, then he or she should not be surprised to see project teams avoiding or working around them. Open, two-way communication and teamwork is critical to your success.
You need to maintain legacy documentation. The information administrator needs to develop and maintain documentation and models about legacy data sources. Ideally the owners of the legacy systems are responsible for the models, and the information administrators will just need to have access to them.
You need to maintain an enterprise data model. You (optionally) need to develop an enterprise data model, based on your enterprise domain model. A domain model is typically high-level, whereas your enterprise data model will typically have more detail. Although enterprise data modeling is often viewed as an enterprise business modeling endeavor, the reality is that the information administrators are the people who develop, own, and support this model.
You must comply with external regulations. External regulating bodies and legislation require organizations to comply with their specific regulations. From a legal and ethical standpoint, remember that ignorance is not an excuse for non-compliance. For example, in the USA, the Sarbanes-Oxley (Sarbox) Compliance Act of 2002 (US Government 2002) requires public companies to document their financial processes and show how the data were calculated, including traceability back to the source, and the Health Insurance Portability and Accountability Act (HIPAA) of 1996 (US Government 2004) provides federal protection for US workers. Ensuring that you comply with relevant guidance is a small part of IT governance that information administrators cannot ignore.

The next activity for the information administrator is the management of IP; this is critical within organizations because it is a valuable resource. An additional activity performed by an information administrator is license management. License management is important from both a cost and legal standpoint. From the cost standpoint, you do not want to be overspending on licenses for software that is unnecessary. From the legal standpoint, the last thing you need is someone from the Business Software Alliance (BSA) showing up at your organization with claims of piracy of commercial software; besides receiving negative publicity, the imposed fines are steep and can have an impact on your financials. License compliance and adherence to standards are often the last things on the minds of developers, so enterprise administrators will need to mentor and guide teams regarding these issues.

4. Managing Security

There are two different types of security that a security administrator needs to address:

Physical security includes the measures an organization takes to control access to restricted locations; this type of security is to help prevent terrorism or some less intrusive security breaches.
Information security includes action taken to prevent unauthorized access to organizational data and is performed at the IT level; this type of security is to help prevent cyber-terrorism, hacking, or types of industrial espionage.

The melding of both physical and IT security is called convergent security, which is being heavily pursued and supported by both types of security vendors today.

A security administrator should be involved during all phases of the EUP, from setting up new security aspects at project inception to ensuring that after a system is retired, everything from a security standpoint is in line with the organizational guidance. Security administrators must address the following issues:

Enterprise IT protection
IT budgets for security
Security infrastructure build out
Look internally for threats
Security education
Operating system flaws

5. Supporting Project Teams

The primary danger of the Enterprise Administration discipline is that you will create a huge bureaucracy to implement it. Instead, your goal should be to streamline the activities of this discipline so that application teams will want to work with enterprise administrators instead of work around them. You need to communicate with the project teams and gain their respect and trust while educating and supporting them. In short, be as agile as you possibly can for your situation. It is critical that each type of enterprise administrator develops the relevant guidance for his or her specialty and then supports project teams in its application. If the guidance reflects common best practices, if it's written well, if it's easy to conform to, and if it's supported effectively, then project teams should be willing to follow them; you should expect project teams to resist following your guidance otherwise. The guidance includes:

Network and hardware guidance. Describes the types of network devices and protocols supported, how network outages will be handled, and how to help prevent system downtime outside of the normal maintenance windows. This also includes the standards for hardware usage within your organization, financial depreciation recommendations for computing systems, and recommended sources for required purchases.
Facilities guidance. Describes the organizational standards and guidelines for procuring hardware and other infrastructure items (such as cubicles and conference room sizes and layouts). Also describes the timelines and projections for physical growth within the organization.
Data guidance. Describes the data quality management directive or activity, the concepts that support it, any associated roles and responsibilities, and any technical, operational, or administrative implementation details.
Security guidance. Describes password policies (and enforcement), specific hardware and software vendors to work with on security issues, and how to keep security software (such as anti-virus or anti-spam definition files) updated. It describes the differences between physical and IT security along with ways that they are converging within the organization.

6. Summary

The Enterprise Administration discipline within the EUP extends the RUP to cover the administration needs from an enterprise level. This discipline includes managing both physical and information assets and the security for the enterprise; it also includes information on how to support project teams with the various initiatives and activities within this discipline.