After spending the better part of an hour on a soapbox pontificating for the umpteenth time about a subject near and dear to my heart, I thought I would attempt to capture it in writing to -- just possibly -- save myself a future call.
I'd been with [company elided, the problem is generic and naught to do with any particular company] for a few years and I've been deploying "large enterprise" applications for more years yet. Now the meaning of both "large" and "enterprise" differs greatly today from what it did 15, 10 or even 5 years ago but, importantly, the basic challenges and necessary processes, procedures and politics of deploying what is "large enterprise" of the day do not differ very much at all. What are those challenges? They are many and varied but as general buckets:
- User Diversity -- while the scope of "enterprise" may have changed from 100s to 1000s or even 10s of 1000s of users and beyond, it has always included the notion of what today we call "multiple business units". The challenge is that different end-user populations require different things from a single application. This has architectural, support and cost implications.
- Scalability -- again, the bar is continually being raised but there is always a scalability issue and always a limit. There will nearly always be a desire to push the envelope of the solution, to "get the most out of the solution", Enterprise Applications are Expensive, and the very hard part is determining exactly where the performance impact induced by load starts to negatively impact the productivity of the end-users.
- Network / Geography / Connectivity / Bandwidth / Latency -- a big bucket of problems that are inherent in any Enterprise Solution. While it might be nice to think that the network designers are completely in tune with all of the applications and uses of their network, regardless of LAN, WAN or Global WAN -- it's not likely to be the case in many organizations (if any). Some will go to the effort of listing and ensuring only the allowed applications are in use and even classify them in some way (web-based, client-server, etc) but to actually look at and track the final application to ensure that all network end-points are provided with adequate service is so rarely done it is worth reporting on when you do see it! Nonetheless, there is probably no single largest contributor to poor user adoption and/or dissatisfied users then the problems induced by network issues.
- Security -- All three of User Diversity, Scalability and Network increase the risk exposure and therefore the necessary involvement of Security. The diverse set of users means that the underlying content is likely to be diverse and have varying risk associated. When looking at scale you also have to look at distribution of servers, data and the intra-service communications. The Network issues can easily add a layer of access to some heretofore inaccessible piece of content of some end-user. Where Security can all but be ignored at the internal departmental level, it is front and centre at the Enterprise level.
An astute reader will note that I have not mentioned any particular state-of-the-art application nor need I have. These are the very same sets of issues and complexities I and the team I worked with looked at while we provided various Enterprise Solutions to the table 10 to 15 years ago -- applications like "a centralized email location for all 35,000 students, professors and staff utilizing the state-of-the-art fibreoptic 10BaseT backbone connecting the 100s of 2BaseT LANs (a task a junior network engineer might be able to do today but at the time it took a team of well over 2 dozen people with committees and sub-committees, senate reports; very high visibility. We had many examples of such: "Campus Wide Kermit Access", "Campus Wide PPTP Access", "Internet for all undergrads", "Single Source Repository for All Applications" -- simple stuff these days but "Enterprise" just the same. Why? It cost a lot of money, plain and simple.
So what has all this to do with [company] and why do I "get on my soapbox"? Well, the plain simple truth of THAT is that many well-intentioned people do not understand those challenges and propose or (all too often) attempt to provide services suitable for a departmental deployment of an application to an enterprise deployment. Because the above inherent complexity is not understood, the other constant in the equation (the ever-present pressure from the customer to keep costs down) has too large a pull -- the SOW is cracked with insufficient time to account for the work that needs to be done. Too much reliance is placed on the skill set of one (probably unknown and not chosen at the point of SOW creation) consultant.
I hope it is obvious that an Enterprise Solution requires a team. Any single person who tells you they can solve all the issues in any discipline connected with an Enterprise Solution (technical, network, scalability, user adoption, etc) is selling snake oil. Virtually all Enterprise Solutions approach chaos in the complexity involved -- to say there are a lot of moving parts doesn't come close to covering it.
We, as humans, necessarily chunk things to allow us to deal with such complexity -- sometimes we do this explicitly (e.g. we have network administrators who are different from system administrators who are different from application administrators) and sometimes implicitly (eg: web applications can usually be abstracted to web server, DB, and storage) but the point is that we have to chunk it up to understand it -- try to look at an entire end-to-end transaction at the code-level and you WILL absolutely "be unable to see the forest for the trees". But make no mistake; whether we choose to look at the complexity, it is there.
This extends to the SOW level; we cannot expect that we have any consultants that can alone fulfill a service for an Enterprise Solution Deployment, you MUST BUILD IN PEER REVIEW and PEER SUPPORT into the process! This is not an admission of failure; rather it is the proper and expected route to successful deployments. In the same vein, you MUST BUILD IN AN ITERATIVE PROCESS -- only by sheer luck will any deliverable be perfectly acceptable on first draft, again irrespective of discipline -- this isn't just true for technical / architectural consultants but for project managers, coders and even technical writers.
The customer will also have a big team, many members of that team will want input, some will wait until the document is created to recognize their input is required -- others like to wait so that they can say "I told you so" -- POLITICS IS IN PLAY, always. Small companies RELY on "hot-dogs", "jack-of-all-traders", or as I prefer to call them "superstars" because these consultants MUST wear many hats -- there just aren't enough bodies. Big companies have the critical mass to form competencies or specialties -- today we call them communities -- they provide the foundation for the creation of the team REQUIRED to deploy a service. GATE
Village can help small companies act like big companies – it isn't necessary to have the permanent specialists, it is only necessary to be able to access them. kinch
