When to Hold'Em, When to Fold 'Em, and How to Share the Pot
by Thomas N. Pardee, Paragon Solutions
Enterprise Architects know that all too often decentralized development groups ignore architecture, standard technologies, and other guidelines. It takes cajoling, psychology, alliances, trading, confrontation, and sometimes minor deceptions to obtain a win on an important issue. Sometimes nothing works.
Being an architect in these conditions is like being at a card table, deciding the value of the cards project by project. Architects make very fine judgments to decide if the hand is strong enough to drive architectural issues, if there is a strategy that is worth pursuing, or if countercurrents within the enterprise � politics, business imperatives, budgetary constraints, or other considerations � are stronger.
Learning when to hold �em and when to fold �em is important, but it describes, at best, a truce between technical groups. When a standoff does not represent a �win� for the enterprise, we need to look for a different approach.
Balance of Standards
Management of the technology portfolio is one area where the standoff causes problems. In this area, for many enterprises, enterprise architecture is simply unable to enforce standards. The standoff leads to an approved tools list with redundancy in many categories. For a determined development group, receiving an exemption may be just a formality.
Under such a state, the enterprise ends up with a smorgasbord of operating systems, programming languages, databases, ETL tools for data warehousing, report writers, and everything in between. New projects continue to incur additional costs to bridge these technologies. Over time, the enterprise will face a continuing conversion expense as it tries to standardize and eliminate underutilized platforms. Conversions like these risk disrupting the user community or impacting relationships with customers or partners
Adding insult to injury, many enterprises are paying for a large number of tools and licenses that remain installed and unused.
To solve this problem, we must cut through the standoff between enterprise architecture and decentralized development teams. To do that, we need to understand the dynamics operating on development teams.
First, we must accept the decentralized development environment. Service-oriented teams have won against �efficient� centralized teams for most development. This results in part because more projects support front-office needs, and highly responsive teams must be close to their constituents. Even world-class enterprises with tight control over backend processing will grant their operating companies broad leeway in their front office operations (and the systems that support them). In this reality, enterprise architecture must see itself as a second-tier support organization, not a dictator of technologies, and it must be able to serve from a distance.
Second, development teams need access to information and support from the moment their client hints at a project. The fact that Enterprise Architecture has designated enterprise-standard technology and tools does not mean that the development team has ready access to the needed information. On the other hand, tool and staffing vendors are quick to fill any information vacuum, and a development team under pressure will naturally respond to a highly motivated, proactive vendor. Realistically, Enterprise Architecture cannot be structured and staffed to compete with vendor marketing organizations.
Third, development teams are severely constrained to meet client functional needs within tight operational budgets, and enterprise licenses are not always the least-cost alternative. A tool that is less feature-rich may meet project needs, and a hungry vendor may offer heavily discounted licenses to gain a foot in the door. Sometimes internal policies get in the way as well. There are cases where the internal chargeback for an enterprise license is more than the price in the open marketplace, presumably because of adding overhead. Such practices create a disincentive to adhere to the standard.
Competency Centers
A competency center addresses these realities while lowering the barriers to adoption of a selected technology. In particular it offers these incentives:
- Help with feasibility studies; with performance, functionality, and reliability results from within the enterprise; and unbiased vetting of the proposed application to assure it is a good match for the tools capabilities
- Fast-start support such as access to prepared development and testing environments
- Assurance of a smooth transition into production, by providing a common migration platform and migration expertise
- Insurance against rogue application teams by enforcing design and coding standards and compatibility testing
- Production support of the tool, including management of production patches
- Management of new releases of the tool, including initial evaluation and compatibility testing (although the application support team may perform additional testing)
The competency center model is scalable from a single center for a centralized enterprise, to a hub-and- spoke organization with numerous small centers around the globe. Minimal capability for each center includes: a manager and/or lead analyst(s) charged with advocacy and client service; concentration of expertise, training, best practices, customized methodologies and other assistance; standard service level agreements; sponsibility for vendor management; and standards and procedures for development, testing, and migration of applications. In addition, there must be capability for enterprise wide support issues (testing new releases, setting enterprise-wide standards, etc.); it must be part of the competency structure and have a presence in operations centers.
Additional services that they may provide include: lists of approved resources; documented best practices; defined boundaries for tool use; standard configuration specifications for local installation; templates; resources for seeding projects; and training in standards, templates, guidelines and best practices
The competency center justifies itself on the balance sheet by reducing costs for individual development teams through reuse of hardware, expertise, and (ideally) design and development objects. It reduces startup costs associated with setting up and debugging special environments and tool tuning, and also by providing special skills on an as-needed basis. Additional justification is based on greater control and consistency in operational support, more leverage with the vendor, and a single point of testing for new releases.
Vendors look to competency centers to assume the first-level support and provide a single point of contact within the organization, but they also help the vendor sell product while getting around the shortage of readily available expertise. Both the vendor and the enterprise expect to benefit from broader acceptance and use of the product.
In short, the successful competency center must establish standards for the use of the tool, gather and champion best practices, help local teams with architectural design issues, and set production standards. It may also supervise tool-level production support, approve new releases, and provide other services as are cost-effective. Less tangible payback includes reduced training and simplified redeployment of development staff.
A competency centers lives on the boundary between development, application support, and computer operations. It includes management of hard assets, like hardware or source code. It also provides concentrated knowledge, best practices, and special expertise needed to get the most out of complicated tools. It sets standards for all development teams to live by, and it manages the shared facilities for the mutual benefit of users. It is owned and managed by IT.
Touchstones of Archtecture
But although competency centers are a part of the IT, their success depends on design and guidance that are architectural touchstones. At selection time Enterprise Architecture determined the bounds and limits within which the tool could meet enterprise needs for stability, reliability, scalability, security, and other measures. Enterprise Architecture must stay involved to assure that the actual implementations realize this potential.
Through the competency center, Enterprise Architecture can promote use of the selected tool and assure that the use is within the defined limits and guidelines. Ready models, templates, and other architectural artifacts help assure that project teams will use the tool. For low risk applications, the guidelines, standards and best practices may be administered by the competency center, alone. For high-risk projects or unusual circumstances, escalation procedures can involve architecture directly in design and prototyping. Finally, architecture manages revisions to guidelines, standards, and recommendations as needed for new releases of the tool, corrective patches, and new functionality.
Most importantly, architecture has a big self-interest in the success of competency centers, in at least two ways. First, competency centers are all about primary architectural issues: standardization of technology and tools, reusing artifacts and knowledge sharing. They provide an opportunity to propagate architectural values proactively at the enterprise level.
Secondly, the competency center are a showcase for Enterprise Architecture to use in building working relationships with project teams and the distributed enterprise that they serve. Architecture fulfills its primary obligation of propagating architectural values, while building a network of support with development organizations that assures future success and increased influence.
Competency Centers are not appropriate, or even needed, for every tool choice, but they frequently serve an organizational function in which IT and enterprise architecture can share a pot and the enterprise wins.
About the Author
Tom Pardee is a founding member and editor
of publications of Worldwide Institute of Software Architects
(WWISA). He works at Paragon Computer Professionals Inc.
in Cranford, NJ. Reach Tom at [email protected].
