Agile Enterprise Administration: Beyond Data Administration AgileData.org: Techniques for Disciplined Agile Database Development
Home  |  Agile DBAs  |  Developers  |  Enterprise Architects  |  Enterprise Administrators  |  Best Practices  |  Agility@Scale Blog  |  Announcements  |  Contact Us

An enterprise administrator is anyone who is actively involved in identifying, documenting, evolving, protecting, and eventually retiring corporate IT assets.  These assets include corporate data, corporate development standards/guidelines, and reusable software such as components, frameworks, and services. The responsibilities of this role potentially includes, but is not limited to, the responsibilities associated with traditional roles of data administrators, network administrators, reuse engineers, and software process specialists.  Many organizations, particularly larger ones, will split these separate roles out, but for the sake of simplicity I'll simply talk about the general concept of enterprise administrator.  In many ways enterprise administrators are the “keepers of the corporate gates”, supporting project teams while at the same time guiding them to ensure that the long-term vision of the enterprise is fulfilled.  An important goal is to guard and improve the quality of corporate assets, including but not limited to data.  Good enterprise administrators are generalists with one or more specialties, one of which could be data administration, who understand a wide range of issues pertinent to the enterprise.

It is possible for enterprise administrators to take an evolutionary/agile approach to development, if they choose to work this way (many unfortunately don't, see below).  Effective enterprise administrators:

1. Work in a collaborative manner.  They work side by side with people on project teams as needed.  They don't dictate or try to enforce standards or procedures nor do they try to control the project team.  They realize that their primary goal is to enable teams to effectively work within the bounds of their organization, and that the most effective way to do this is through collaboration.

2. Work in an evolutionary manner.  Enterprise administrators will need to support agile software development teams, and because these teams work in an evolutionary manner the enterprise administrators must also work this way.  The implication is that the administrators won’t have complete project artifacts to work with – e.g you can’t insist that a development team puts a logical data model in place before you’ll help them to identify potential data sources.  Agile teams take an agile approach to data modeling and will refactor their database schemas as needed.

3. Communicate their role.  Agile software development does not take a command-and-control approach to management.  Agile developers aren’t going to jump through the hoops of enterprise administrators just because that’s the way things are done, instead they’ll work with the enterprise administrators when the administrators actually have value to add to the overall effort.  Therefore not only should enterprise administrators be able to add value they also need to ensure that their customers perceive that they’re able to do so.  Trying to “impose your will” through onerous processes or management edicts won’t work very well, instead people will find ways to either ignore you or go around you.  In fact, there is a technique called blocking which works incredibly well in practice.

4. Mentor agile software developers in corporate standards and guidelines.  The goal is to support the standards and guidelines, not enforce them.  A good rule of thumb is that if you need to act as the “standards police” then you have lost the battle.  Furthermore this failure is very likely your fault because you didn’t communicate the standards well, didn’t gain support, or tried to enforce unrealistic guidelines.  If the standards and guidelines make sense, if they’re written well, if they’re easy to conform to then data and application developers will be willing to follow them.  However, when the standards and guidelines aren’t appropriate or place an inordinate burden on projects then enterprise administrators should expect pushback.  Yes, some individuals may chaff at following standards and guidelines but that’s something that project coaches/managers will need to deal with. In fact, agile methods such as XP include a practice called Coding Standards which insists that XPers agree and adhere to common coding guidelines, and Agile Modeling (AM) includes a practice similarly called Apply Modeling Standards which insists that modelers agree and adhere to common modeling guidelines.

5. Be willing to actively address issues.  When pushback occurs an enterprise administrator works with the project team(s) explore and address the problem.  Perhaps a standard isn’t appropriate for a new technology.  Perhaps existing logical data definitions need to be updated to reflect new usage.  Perhaps the network needs to be upgraded to support a new application.  Enterprise administrators must be willing to actively work with project team members to resolve issues such as this.

6. Work with the enterprise architects.  Enterprise administrators work closely with enterprise architects to communicate the constraints imposed by the current environment to the architects.  More importantly the enterprise administrators need to understand the future direction envisioned by the enterprise architects to ensure that their efforts support the long-term direction of your organization. 

7. Adopt a lean approach to data governance.  Traditional, command-and-control approaches to data governance appear to work very poorly in practice.  The 2006 DDJ survey into the current state of data management practices showed that 66% of development teams will choose to "work around" their organization's data group, and when they do so that 75% of the time it is because they find the data group too difficult to work with, too slow to respond, or that the data group doesn't provide sufficient value to justify the effort of working with them (see Figure 1 below). This is clearly problematic.  It is possible to take a lean/agile approach to data governance.

8. Take an agile approach to Master Data Management (MDM).  The goals of MDM are to promote a shared foundation of common data definitions within your organization, to reduce data inconsistency within your organization, and to improve overall return on your IT investment. There is nothing inherently special about MDM -- it doesn't need to be complex nor bureaucratic -- you can in fact take an agile approach to MDM if you choose to.  The critical concepts to accept are that MDM is both an enterprise-level issue and a project-level issue, and that the only way for MDM to succeed is for it to enhance data-oriented efforts on development projects and not hamper their overall progress.  Traditional approaches to MDM typically do the exact opposite, and as a result struggle to provide value.

Figure 1. Reasons why development teams go around data groups.

Although enterprise administration should be straightforward, and it can be, many evolutionary/agile development teams find existing enterprise administration groups difficult to work with.  Some of that difficulty lies in a weak appreciation within agile methods of enterprise issues (hence the importance of Agile Data's 2nd philosophy), but most of the challenge lies with the inflexible, often bureaucratic, and often serial approaches preferred by the administration groups.  Much of the problem lies in the administration-oriented frameworks such as Control Objectives for Information and Related Technology (COBIT) and Information Technology Infrastructure Library (ITIL) which are invariably implemented in a command-and-control, instead of a collaborative, manner.  COBiT and ITIL each have some good ideas in them (ITIL seems to have more, IMHO), but like development processes based on the Capability Maturity Model (CMM) Integrated (CMMI) the final implementation often proves to be less than effective.  Worse yet, from what I've seen, many organizations are attracted to these frameworks because they're seen as the first step towards outsourcing portions of your IT organization: get a well defined process in place, get good at following it, then start outsourcing to lower-cost companies who have also adopted those frameworks.  The good news is COBiT hasn't gained much of a foothold within the IT community, and considering how long it's been since it was inflicted on us my hope is that it never really will.  ITIL, on the other hand, does seem to be gaining in popularity so hopefully we can make it effective by tailoring agile concepts into it.

Suggested Reading

Agile Database Best Practices Agile/Evolutionary Data Modeling Agile/Lean Data Governance Best Practices Agile Master Data Management (MDM) Best Practices for Lean Development Governance (Part 1 of 3) Best Practices for Lean Development Governance (Part 2 of 3) Best Practices for Lean Development Governance (Part 3 of 3) The Criteria for Determining Whether a Team is Agile Database Regression Testing Enterprise Modeling Anti-Patterns for a list of common problems which enterprise teams suffer from. Evidence that Agile Software Development Scales Extending the Rational Unified Process with Enterprise Administration.  The Enterprise Administration discipline extends the RUP to define how an organization creates, maintains, manages, and deploys physical and informational assets in a secure manner. Imperfectly Agile: You Too Can Be Agile for a discussion of why some common reasons for being more agile are nothing more than flimsy excuses. Introduction to Data Normalization Join the Evolution (Software Development, May 2005) On Relational Theory The "One Truth Above All Else" Anti-Pattern Process of Database Refactoring The Quest for the Silver Bullet Questioning Traditional Data Management Reining In IT: An Agile Approach to IT Governance.  This article describes approaches to effective IT governance which are compatible with agile software development. Roles on Agile Teams: From Small to Large Survey Results (Agile and Data Management) Why Agile Software Development Works: Improved Feedback When is Enough Modeling Enough? The EUP is an extension to the industry standard IBM Rational Unified Process (RUP). Whereas the RUP defines a software development lifecycle, the EUP extends it to cover the entire information technology (IT) lifecycle. The extensions include two new phases, Production and Retirement, and several new disciplines: Operations and Support and the seven enterprise disciplines (Enterprise Business Modeling, Portfolio Management, Enterprise Architecture, Strategic Reuse, People Management, Enterprise Administration, and Software Process Improvement).

	This book demystifies enterprise architecture and helps organizations recognize real business value through effective implementation. Written by expert practitioners who have hands-on experience solving real-world problems for large corporations Helps enterprise architects make sense of data, systems, software, services, product lines, methodologies, and much more Provides explanations of theory and implementation with real-world business examples to support key points.
	This book describes the philosophies and skills required for developers and database administrators to work together effectively on project teams following evolutionary software processes such as Extreme Programming (XP), the Rational Unified Process (RUP), the Agile Unified Process (AUP), Feature Driven Development (FDD), Dynamic System Development Method (DSDM), or The Enterprise Unified Process (EUP).  In March 2004 it won a Jolt Productivity award.
	This book describes, in detail, how to refactor a database schema to improve its design. The first section of the book overviews the fundamentals evolutionary database techniques in general and of database refactoring in detail.  More importantly it presents strategies for implementing and deploying database refactorings, in the context of both "simple" single application databases and in "complex" multi-application databases.  The second section, the majority of the book, is a database refactoring reference catalog.  It describes over 60 database refactorings, presenting data models overviewing each refactoring and the code to implement it.
	This book presents a full-lifecycle, agile model driven development (AMDD) approach to software development.  It is one of the few books which covers both object-oriented and data-oriented development in a comprehensive and coherent manner.  Techniques the book covers include Agile Modeling (AM), Full Lifecycle Object-Oriented Testing (FLOOT), over 30 modeling techniques, agile database techniques, refactoring, and test driven development (TDD).  If you want to gain the skills required to build mission-critical applications in an agile manner, this is the book for you.

Let Us Help

We actively work with clients around the world to improve their information technology (IT) practices, typically in the role of mentor/coach, team lead, or trainer.  A full description of what we do, and how to contact us, can be found at Scott W. Ambler + Associates.