It’s to share some experience and knowledge for building standards and deciding what should get standardized.  An organization can often lack in standards for both technology and business processes – we’ve all seen those organizations.  Very often they are disorganized and generally unprofitable.  This supports an environment of complexity, as standards help to ensure those who require the structure can build and grow at an appropriate pace.

Other organizations can have so many standards, especially in process, that they are hamstrung to do anything that doesn’t fit the mold.  Take your friendly neighborhood utility for an example.  Ever try to figure out who to call in such a large organization, or ask for information on something that isn’t their every day common situation?

They almost seem unable to think or speak to what the potential solution might be because they are so used to looking it up in their policy books. So what kinds of standards should an architect strive to gather and maintain?  Think about your four pillars of the standard enterprise architecture – business, information, application and technology.  The last three are the three most common areas to create standards for, while the first is the most common to set up processes for.  Within each of these standards, the architect should strive to have standards around modeling, artifacts, documentation, and source
control.

To drill down further, the data should have data attribute type and naming standards, as well as storage standards.  Database structure and design is another area which should be standardized.  Processes should be created around back up and recovery, upgrades and installations.  Ad doc data fixes should always be scripted, and standards should exist about how they are written and where they are stored after they are executed.

Applications should have a large focus on standards, the biggest of which should start with a standard application framework.  Following this should be button, navigation and menu standards, pattern usage and development standards, error message and testing standards, as well as usage, and user interface standards.  This list is definitely not exhaustive, but it’s a great start.  Naming standards are always a party favorite – why not throw them in as well? Technology is probably the most intensive area for standards and definitely most easy to document.  Many technology standards are inclusive within the tool or technology being used. These are typically the most stringent and necessary as the application and information staff are very dependent on knowing them in order to develop and maintain systems, as well as to actually make these run and work.

With all of these standards, there is a possibility that too many of them can be created.  Doing this will cause an incredible amount of effort to maintain them, and can cause an environment of rigidity.  It is good that there are enough standards to create an environment of creative tension, allowing new ones to be embraced through technology advancement and governance.  This would be the ultimate level to aspire towards, but it is very difficult to keep this under control, while not going to far, and continuing to go far enough.