Architecture without an Effective Enterprise

So what are some of the issues that arise when a large company does not have an Enterprise Architecture group? How could this happen, especially in a company which is dependent on validated systems and many different and competing standards?

• Business Partners are frustrated with the lack of governance and execution of projects that matter to them. The project pipeline for smaller projects is large. The large projects get funding to trump the smaller ones, pushing the smaller deployments back by years. The Business threatens and sometime does build its own solutions.
• Project liaisons like Business Relationship Managers, Project Managers, and Business System Analysts are overwhelmed and focus mainly on timelines, milestones, and deliverables without knowledge of other projects and synergies that might be available from an architecture perspective. There will be different levels of training and experience across application specific groups.
• The Service Delivery Team lines up resources and figures out who can do what, when, and thinks everything else will just have to work. The issue is that other outside team resources may not be considered by the Service Delivery Team. For example, the infrastructure team may be working on 10 other different build outs and there’s no priority.
• Solution Architects will clash with Network and Storage Architects who are blindsided by project changes and overwhelmed by lack of resources. The documentation of each group is not consistent. There will be no overarching document template standards across the application stacks. There are 15 different icons in Visio diagrams that represent servers.
• Large Consultants will infiltrate easily into the heart of ERP and ECM and try to get into Legal and Records Management. These consultants will suck big bucks out of IT’s coffers. Knowledge transfer will be an after thought and spotty at best. The stability of process and deployed applications will take much longer to achieve.
• The Integration Team will be very busy patch holes with webservices and other protocol, but there is no EA team looking at the whole wall of patches to determine where the future cracks will be. Each patch is customized with different metadata requirements, no common values, no Moreq2-type analysis. The testing of upgrades across integrations is too little, too late. For example, there is a general lack of awareness of the full impact of changes made in Active Directory.
• There is no overall orchestration of applications, integrations, standards, ROI, and cost controls. The budgets for projects and their corresponding SLAs are out of balance. The downtime for upgrades blows away the accepted downtime window.
• Priorities of projects lack coordination of architects experienced with building platforms which scale. IT Governance touts its own top 10 projects, while ignoring the priorities of the business partner’s projects and initiatives. For example, deploying Sharepoint 2010 with complete confidence in the first release vs. holding off on a major ECM upgrade until the first or second point release, even though the business is clamoring for the new ECM functionality, eg. Center Stage… Another example would be launching a large project with two versions of the same application because in the time it takes to deploy a new version is up and user are clamoring for its features.
• Records Managers and Legal Departments will be forced to drive metadata standards at the enterprise level. They will most likely be stonewalled at every turn, especially by IT.
• The Infrastructure architects are explaining too much and doing too little. One person questions the amount of storage required because of cost and another says don’t worry about the money. The racks in the server room have blades tucked into spaces that are not shelves. The power supply of the server room is maxed out. There is no coherent Storage strategy for expansion. Records Management and thus disposition is far down the road.
• There is a high churn rate of smart developers and architects. There aren’t enough incentives to keep them. They are too busy putting out fires so they quit and move to companies with EA teams in place.
• These are some of the issues that arise when a medium-sized company grows into large one. However the EA team should be in place from day one. All companies should recognize the importance of standards and centralized governance of IT architecture.