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.

Sharepoint and the “Others”

If you watch the TV show “Lost” you’ll know what I’m talking about when I say that Sharepoint is one of the survivors of Oceanic flight 815 and Documentum, Open Text, IBM, Oracle are the “Others”: the ones who are indigenous in the ECM space, the island. The Others are adept at moving around on the island. They know the lay of the land and the dangers that lurk at every turn on the trail.

Sharepoint is poised to set up camp on the easy to reach, safe locations like the nice beaches, or in the collaboration and project oriented areas of the enterprise. The Others will lurk in the deep jungle holding onto their strongholds. As Sharepoint becomes more equipped to fight the Others and outsmart them, the old patterns of ECM will evolve; Sharepoint propogates and splits into factions; there is no central goal or common standards in the way Sharepoint is used and spread.

This Sharepoint scenario is very similar to the internet boom. Remember what happened when the first wave of intranets hit? Individual business units spun their own websites overnight and they catered to their own unit’s requirements. Everyone was happy among themselves in their own insulated groups until the Others took out their sticks and started asking questions like, “what’s your metadata model?”, or “does this site scale?”, and “Can you search this thing”, “do you have a review and publishing process?”, and so on.

These “shadow IT” groups were slowly consolidated, shunned, taken off island, until at last a centralized ECM solution was implemented. The ECM solution was great for IT, with its centralized support and architectures. The problem was it took an act of god to add new functionality and it was expensive. The more centralized the ECM solution got, the more business units wanted to break away and fulfill their own needs. Enter Sharepoint: small and uncoordinated at first. But now with SP 2010 the Others are no longer that dangerous. The Others needed to evolve, but did not morph fast enough. The Others now are hiding in the strong holds of records management, index/search, business and forms processing, case management, scanning, and license agreements. The Others will be forced out eventually to face Sharepoint. Google and open source will follow in pursuit as well.

Meanwhile as business units go wild with Sharepoint and architects run behind them trying to put RM, metadata standards, storage in place, Sharepoint will be dealing with its own issues. The silos of information will not be fixed by technology, by search. Info silos will only be fixed by continuously evolving and releasing easier ways to institute standards and conventions around organizing/normalizing data and content. As soon as the structure of lists in Sharepoint is deployed, the structure will have to change. Sharepoint may well go the way of individual intranets. Getting the business as a whole to agreed on certain rules and policies and to comply with best practices is the real issue and IT can't do it alone.

Let’s hope the user’s obsession with the UI will go away and a new vision of usefulness and knowledge building and sharing will arise. Knowledge Management of the 90’s is just morphing into collaboration and search. Who knows what, where, when, how, and why is the framework to design to. Integration of desperate services by common interoperable factors (CMIS) is one of the keys. The Others have known this, but have been driven to distraction by profits and the friuts of the jungle. Now, as the island is rumbling for change, the Others will have to change their tactics and listen to the island for future instructions.

Documentum vs. Open Text Content Server

Open Text Content Server and Documentum grew up together during the same time, but in different neighborhoods. Sometimes I wonder how certain architectural design decisions were made, or how lack of funding may have affected the level of integration between the products in their respective software suites. When compared with DCTM, OT is like an old Mustang and DCTM is a newer Toyota with recall issues. This is by no means a comprehensive comparison of the two software suites. It points to some important ECM aspects and tries to expose some of the issues and precularities.

Session Thread Model
OT has an understood session thread limit of 5 per server. Can you imagine this with DCTM? OT will fix this with their 10X release, but customers have suffered for years with this limitation. Session management in DCTM is mature, but has its own issues. So in OT the way to scale for many users is to build out Livelink servers (5 session threads) per server. If you had the potential for 30 concurrent sessions, then you’d have to build out 6 server instances. These OT instances would have to have all of the modules, patches/fixes, on each. This is 6 times the deployment effort. It took OT 10 years to scale concurrent sessions on their base server kernel?

DocBroker vs. Nothing
Here’s a real big issue with OT: failing over one repository to another. OT just can’t unless you want to purchase archive server which is not really part of the LL server and not pertinent to this. OT relies entirely on load balancers for distributing client requests. Yes, the docbroker has its issues too, but at least it can be used to failover one repository to another.

Object Model
Because Open Text doesn’t have the foundation classes that Documentum has it is hard to conceptualize the inheritance model and relationships between the underlying database tables.

dm_sysobject : DCTM’s main table which holds the chronicle and object ids of most of the objects in the repository (dm_type, dm_user, dm_acl are related by not derived from dm_sysobject). Document objects extend from this table in the DFC and are related to separate doc tables per configured doc type. Both architectures have main tables which are related to be most other tables. This has its pros and cons. Let’s take a cursory look at both models and try to compare some key areas.

Dtree: OT’s main table which holds the data id of all objects. If you look at the schema, it’s like a wheel with spokes all leading to the dtree hub.

Version Trees
If you ask an experienced OT administrator if there is a parent id to a document id, chances are he would not know the answer or he might even ask why is this important? Version in OT is not an option. In DCTM at least there’s a way to control versioning during the work in progress states.

dm_sysobject: The parent id of a version is the chronicle_id which holds all of the object_ids. The chronicle and object_id are in the dm_sysobject table.

version tree: dm_sysobject chronicle_id and object_id


dtree: The parent id of a version is the docid which is in the dversdata table and the version ids are in that table as well. The key between the dtree and dversdata table is the dataid which is the docid

version tree: dtree dataid = dversdata docid then versioned

Given this simple example of versions, you can see that OT’s table join for version look ups of basic system level content attributes may not scale as well as DCTM’s.

Permissions and ACL Inheritance
In DCTM there are separate tables and objects which manage permissions of folders and content, as well as system objects themselves. In OT, there is no such concept: permissions are inherited by default from folders only. In DCTM, ACLs can be inherited by object_type, user, or folder.

OT: folder only
DCTM: object type, User, Folder

If you think about the advantages that DCTM’s model has over OT’s look at how limiting it is for workflows which may rely on changing permissions to an attachment as it goes through the review and approval lifecycle states. In DCTM you set the ACL and you’re done. In OT you set the permissions for each user and group at every state. What a change management nightmare!

Object Types vs. Categories
When I first worked with OT’s categories and understood how they related to content and served as metadata tables, I liked them (kind of a cross between custom object types and aspects in DCTM). Then I learned that if you add an additional value to a dropdown selection, not only do you add it to the category, but the system has to update all of the content metadata as well. Each document is coupled with the UI’s potential values in a dropdown selection box. This is mind boggling. OT’s solution to this is the turn off the modification trigger during the category “upgrade”. This makes me worship DCTM’s value assistance.

DCTM’s metadata inheritance model: the custom object type table inherits attributes from dm_sysobject. This makes the doc type, plus an ACL is associated to each object. UI metadata and document metadata are decoupled.

OT’s categories: all content is dtree content. A custom category is an “object type”. The category metadata and the content metadata are coupled.

As you can imagine this does not scale. One attribute value change in the category has to “upgrade” potentially millions of documents without actually modifying any of the content’s metadata.

Development/IDE
I never thought I’d say this but compared to LiveBuilder, Composer (with all of its bugs) is hands down a superior development environment and deployment tool.

DCTM: Eclipse/Composer
OT: LiveBuilder

UI customizations: WDK/TBO vs. Modules
MVC development in OT is more streamlined than DCTM but it’s more manual and awkward. Deployment of OT’s UI customizations straight forward, like DCTM it requires a web server restart. A bonus of OT is that you don’t have to shag after caches between deployment environments. Despite OT’s cryptic Oscript, I bet the learning curve to be productive in developing it is faster than the WDK.

As far as extending core methods in OT, you’re out of luck. As far as I can tell, TBO/SBO extension customization concepts were never introduced into the OT environment.

DCTM TBO, SBO, WDK: JSP/Configuration/Java Behavior class
OT Modules: Oscript/HTML

Webservices
DCTM wrote the iECM spec for service interoperability. Like DCTM, OT plans to expand and eventually only use webservices for all MVC requests and responses. CMIS adoption and use will slowly rise as large companies sunset their old repositories and bean count the new services into their road maps.


Users/Groups:
OT’s users and groups are keyed by a Number, in DCTM the key is the user/group name or String. Using a number allows OT to manage the changes in User names easier, however there is no such concept as a federation of repositories. OT is designed around a central repository user concept. Users created in one repository will have a different id than the same users in another repository, however the synchronization of AD between environments mitigates this issue.

OT KUAF: Number
DCTM User: String

Potential for Home Grown Mess
The maturity of a repository is directly related to how much resources and attention to ECM standards were governed during the repository’s expansion. If the users were in control of the folders, permissions and content, then chances are you have a mess of projects, permissions that do not scale, and outside URLs that point to the repository’s contents from portals and embedded in documents.

Somehow companies with DCTM seem to be more adept at realizing the limitations of performance and scale when it comes to the difference between consumers and contributors. Maybe it was Webpublisher’s adoption success over OT’s lame attempt at the same.

The concept of decoupling the consumer interface from the contributor’s is what web 2.0 is all about. But both camps have an uphill battle to convert repositories in flexible content architectures.

Storage Management
What can I say EMC owns Documentum and it was a beautiful purchase in terms of storage management. I leave it at that though. OT’s archiver is an after thought compared to the power of taking BCV snaps of servers. Of course only large companies can afford EMC storage solutions…

Developer Community
DCTM developer resources cannot be touched by OT’s. I’m glad I learned DCTM’s solution before learning OT’s. If you are like me and learn the most by examples, DCTM is heaven. Part of the issue is the OT didn’t seem to know that Oscript was a very limiting factor in terms of adoption of OT as a whole. They didn’t get that in-house OT administrators need ways to develop their skills beyond following installation and admin guides. Learning Oscript meant you were locked into OT’s vision and world, but DCTM, Oracle, IBM, etc were out there as well.

Each section above could be a chapter in a book, but this a blog and I only have so much time to elucidate some of the points of comparison. It's hard to compare a teenage to an adult, but it's my opinion that OT hasn't been able to mature as fast as DCTM. This puts it at a disadvantage in terms of competing with Sharepoint and 2.0 technical advances and User's expectations in of UI functionality. So, the ability to be nimble and move with the technical changes in the world will prove which repository is more ubiquitous in 5 to 10 years. Also, our friends the bean counters will help slow adoption of new technology and especially new ways to thinking and expressing ourselves within the corporation.

Documentum Talent Revisited

I recently searched google for documentum talent and came across an article from a fellow ECM blog entitled, “Documentum Talent”. The issue I have with this article is that although it is informative, it only scratches the surface in terms of understanding what takes to create true Documentum Architect talent. Java: yes; OO design: absolutely; ECM experience at any level: priceless.

First of all, the tone of the article is conceited and has one of those boss man attitudes which says, “Technically, I know it all, so don’t question what I’m saying. You are kind of a smart guy, but you are all minions to my brilliance, mere duck tape to my superior abilities…” Some architects are arrogant, but most are mere mortals, stuck between a rock and a hard place, trying to please the users and the bean counters.

Ok, whatever the tone, let’s focus on what is missing:

Business Requirements
I’m sorry, but Java and OO design as core to Documentum developers is obvious. If you can’t find this core in a developer, don’t hire them period. What is much harder to find (and more core) is a developer with business requirements gathering experience. Hello, what does the User want? This is why User’s are flocking to Sharepoint, “Talent” as defined here have been too technical and not business savvy enough. They thrive on xml payloads and not enough UI, search, and ease-of-use. Not mentioning “business” or “User” anywhere in his article on Documentum Talent explains the disconnect that has been going on for years between implementation and design. Talent is not knowing webservices only, it is knowing the “why” behind integration needs? Why CMIS has taken so long to emerge. The reasons behind needing to integrate applications are just as enlightening as the technical solutions that make it happen. Business units fund these applications, IT builds them, architects integrate them, but what decisions were made in the past that required two document management apps, for example, or why was Sharepoint introduced?

Knowledge of Competition
Sharepoint didn’t just appear this year to scoop up ECM. It has been around for years, honing its functionality. Taskspace was a joke, it was buying time for Center Stage which was a few years late. Now we have Sharepoint and Alfresco taking business away in circumstances where the EMC licensing contracts are up and the entrenched Documentum Users are fed up. Technology focused architects have helped create this mess. Just make it faster and improve the SLA, the users will be happy…

Long-term, Goal Oriented
Beyond the politics within an organization, how projects are funded, who is technocrat of what services delivery group, lays the long-term vision of the solution at hand. What role does the solution have to the ECM vision in three years? In five years? What are the overarching goals of IT? Knowing how to work with these, question them, and design to them is very hard to find in our technically “superior” architects. Knowing how the historical impact of ECM has influenced the current design and plans for the future. Who is promoting collaboration and why? These are key to talent. In politics, bringing in Sharepoint is the equivalent of promising jobs to your constituents who have been suffering from EMC’s lack of attention to your needs.

Change Management
I’ve seen many Documentum installations that are OOTB with shortsighted object models, security, folder structure, workflows, integrations, etc. These are the result of profit hungry partners smirking as they write their SOWs. Some partners purposely put their blinders on when it comes to scoping their projects. They know full well that as soon as the current project is over the client will be begging for improvements. These partners purposely take shortcuts because they rely on their client signing on for more work. Technically, the project could be architected well, but the human interaction issues with the software may not have been fully addressed, leaving the user scrambling to duck tape their processes to a UI that is too constrained. Knowing when to give the users something for free is a key sign of good talent.

Sharepoint vs. Documentum: Analyst Perspective

It depends on who's perspective you want to take when you compare Sharepoint with Documentum. Every person has a unique take on the Web 2.0, its marketing and hype, but the bottom line is that it is cheaper than proprietary software and can be an open source application that eclipses both MS and EMC. When I think of Sharepoint, I think of projects and ease of use. When I think of Documentum, I think of content lifecycle management.

Resource Delivery Director: wants one solution, centralized with easy configuration. This person is usually religious on a programming language so depending which one .net or Java, this will be part of the decision. This person has pressure to deliver applications balancing this against resource expense.

Architect: wants scale, performance, and integration, plus local developers. This could be a problem for Sharepoint as good developers work for partners, they are not mature enough to contract on their own. Also, good luck out sourcing to India for Sharepoint folks. That will happen, but not yet. Integration and CMIS are also considerations. What apps are integrated, ease of webservice integration, identity management, workflow, etc.

Chief Bean Counter: wants a good ROI story. If a CIO has a preferred technology, she will find/procure a research study which is a proponent of it.

Users: want something that looks different than what they have, but they want everything they had. Do you put a new skin on an old application, or do you buy a whole new app?

Elephant in the Room: Open Source is coming, so EMC and MS are really on the same side here. Alfresco is not going away, neither are the other players. Google might trump everyone once it can’t grow everywhere else, why not tackle the source?

I have witnessed the demo difference between the two platforms and Sharepoint wins hands down. Partners selling these two products are the front line in this discussion. Partners who sell both are selling one short and hedging their bets. Find a partner who sells either EMC or MS and get their pitches, then write the matrix and gap analysis. Also, throw a third party in there for balance.

The main issues you have to matrix are business requirements and the key stake holders. Also, who’s a member of the steering committee.

There Is No Such Thing As "Unstructured" Information

All information, content, documents, chunks have implicit and explicit context and metadata associated with them, therefore they are structure to a certain degree. One of the major issues of keeping tracking and finding content can be solved if the “who” in the equation is dealt with.

Take Records Management. First, the concepts are agreed upon; second, “we have to get something out” requirements are decided on; third, the tools are picked; finally, the issue of how to tag the information is arrived upon. Oh yeah, the creators of the content. How to get then to change the way they tag information, their habits of thinking around identifying their content for world consumption?

The legacy content is another issue altogether. Are you going to force authors to tag and reorganize their whole c: drive? Are you going to auto categorize the share drive and hope your taxonomy is comprehensive enough? Are you going to set up a master/proxy that layers a meta metadata structure on top of everything? Will there be a hybrid approach to humanly sort out the who, what, when, where, how, why (Zachman).

The point here is that it’s the Users, the corporate culture, that have to change their modus operandi. Sound familiar KM? How many times do we have to come up with applications that work around the ultimate issue of training users to think in terms of the group and the community, of sharing not hording ideas and knowledge? Social applications like Facebook will slowly seep into the minds of corporate Users and break this road block wide open.

Let’s hope that Center Stage grabs this trend and really takes off. If it’s easy to configure during a customer demo like SharePoint is, then maybe it has a chance. The overworked, whittled down IT departments out there want easy to administer enterprise software, that can be mostly configured. As soon as Documentum builds in a more comprehensive configuration tool (yeah I know Composer, right, not quite) the issues of customizations breaking or being too focused will be a problem of the past.

File shares in corporations are not “unstructured”. They actually are very structured, but to an indexing application with a taxonomy, they are “unstructured”. The real issues are change management of User behavior and ECM applications, governance with a small stick, and software that IT can be lazy and cheap about. SharePoint is already the next dumping ground, but User’s have learned just a baby step more about tagging their content so that others can find and understand it.

Diagnosing an ECM illness

As ECM projects and systems grow through awkward teenager years and start to show signs of age, there inevitably comes a time when symptoms of an illness show themselves and can’t be ignored any longer. The existing management is usually blind to the issues. The issues are inherent in how they make decisions and thus restructuring the governance and budget process is usually part of the treatment.

Symptom:

• Lots of Testing on Production and extended down times for maintenance.
  

Diagnosis:

• Lack of QA environment that is exactly like Production to validate test scripts
• The more testing, the more risk of extended downtime and possibility of rollback
  Relaxed emphasis on testing and more attention to deadlines

Treatment:

• Create a QA environment which matches Production down to the hardware (to test server swaps).
• Establish a mandatory QA and Validation process for the QA environment, thus reducing the risk of running major tests in Prod.
• Schedule more time than anticipated for testing in QA
• Budget extra resources for testing
  

Symptom:

• Unorganized folder structures and search results that are useless.

Diagnosis:

• No taxonomy standards
• Lax governance
• Fuzzy goals for business requirements
• No discipline in term of awareness of others who are outside of the team
• No training of common principles of organization
• Poor change management
• No organized Taxonomy: lack of governance, training, standards
• Bad search results: bad metadata, values are too haphazard
  

Treatment:

• Establish goals and standards
• Create a governance structure that can force business units to change
• Study current structures and come up with a plan to rebuild them with the acceptance from the key stake holders.
• Train superusers on information architecture
  

Symptom:

• A call for “re-branding” an implementation

Diagnosis:

• Managers did not listen to the subtle whispers of dissatisfaction with the product.
• UI complaints accumulate, they don’t just happen.
• There are other factors that prevent upgrades to existing software or new software to replace outdated solutions.
  

Treatment:

• Illicit feedback and make changes continually
• Identify the lack of awareness of management to issues of business productivity
• Identify why the system lasted so long in its current condition without treatment
• Create mandates to leap frog to new technology every few years
• Design and architect for change

Symptom:

• Extended Downtimes in Production due to performance and scaling issues

Diagnosis:

• No Failover or HA to fall back on during inevitable times of failure
• Cutting corners on budgeting and resources
• No QA environment for performance testing
• Lack of enterprise architecture plan and resources

Treatment:

• Budget for failover contingency in hardware and software
• Create a QA environment
• Understand the lessons learned from the whole solution development lifecycle: where things went wrong and steps to take to remedy the issues.
  

Symptom:

• Postponing/rescheduling work execution due to emergency, “all hands on deck” system downtime triage

Diagnosis:

• Poor program and project management
• Poor resource management
• Resources that are not trained and experienced enough
• Sign of a series of mistakes during the whole project, no one resource is to blame

Treatment:

• Have clear goals stated up front
• Do not cut corners to meet bogus timelines
• Make sure there is enough time allotted for testing
  

Symptom:

• Slow performance

Diagnosis:

• No architecture plan for scaling of the application
• Lack of performance testing in QA
• Too much leeway given to power users who are not trained enough and only care about their own content
• Poor budgeting process
• No standards for change management

Treatment:

• Transfer the management of the application if this has been going on for a long time
• Architect a solution from the ground up which is flexible and scalable enough to deal with the use and capacity issues
• Think about dividing up the applications if the current one is monolithic

Symptom:

• Stealing infrastructure for other higher priority projects

Diagnosis:

• Poor communication from management of goals and forecasts
• Management is feeling pressure to succeed after a few failures
• Infrastructure procurement process is too slow to be effective
• Resources are frustrated from infrastructure and architecture to implementation teams
  

Treatment:

• Budget and purchase hardware well in advance
• Do not accept a project if it entails cannibalizing hardware and resources from other projects unless the whole teams is fully on board with the sense of urgency

Symptom:

• Infighting during deployment planning meetings

Diagnosis:

• Lack of cohesive governance
• Favoritism within the teams or from higher up
• Lack of trust
• Lack of common understanding of goals or standards

Treatment:

• Create common understanding of goals and standards
• Communicate often and effectively with the team(s)