Friday, July 31, 2009

The Laminated Tenets

The Category II Tenets

These are the types of tenets you can laminate in plastic and frame for the office wall next to the water cooler. They don’t often change, but change they do. These tenets usually define the current state of the industry preferences for specific technologies. While usually applicable to current environments, there is no guarantee they won’t eventually need to be revised. Take a trip down memory lane and imagine a return to the year 1969. Yes, Woodstock happened and you probably don’t remember it, either because you hadn’t been born yet or because you were in fact there. After listening to Janis Joplin, Santana, and Jimmy Hendrix, you show up to the office and are given the task of defining the tenets for a data processing application. You clear your mind and readjust to the fact you are back at work. You define a tenet that states customer records shouldn’t exceed 80 characters. Why? Because each record must fit on a punch card, and a punch card holds a maximum of 80 columns. Clearly, when there’s a need to code for the year field, you’ll opt for conciseness and drop the “superfluous” 19 from the year, etc. Another tenet might have been to make certain that all job submissions are hand-delivered to the “Batch Service” window with the user signing the log sheet.

Unlike Category I tenets that tend to be industry-agnostic, Category II tenets have a more focused applicability. Some of these tenets will be more appropriate for a particular industry segment, geography, or IT situation. If you are in a service industry, for example, you will have tenets that emphasize functionality over other attributes; if you are in the manufacturing industry, you will probably focus on tenets geared to reducing costs, and if you are in the videogame industry, your tenets will highlight usability and playability.

The list of Category II Tenets can therefore be extremely large. Below, I show some such tenets as examples. Again, when it comes to creating your own tenets, you’ll need to assemble your team and map those tenets that best apply to your specific conditions and that contribute to meeting the category I tenets previously defined:

· Move to a common development environment to maximize use of common support processes and tools within any of the deployed platforms.

· Object-oriented methodologies and approaches will be pursued whenever possible. Percentage of reused code will be a success factor.

· Use state-of-the-art programming tools and techniques to ensure maximum development productivity. Use Life Cycle and Service Studio components to facilitate service reuse. Optimize the development cycle by using design methodologies that permit analysis of the system under a business view and rapid prototyping for proof of concept. Use UML whenever possible.

· Ensure reliability through redundant clustering, either purchased or built. The strategy is to seek system level resilience via n-plus one redundancy with automatic fallback/recovery.

· Consider security requirements from the start. Establish security, logging and billing mechanisms based on service-oriented constructs.

· Message queuing is the strategic middleware standard. Mapping to other middleware will be supported as required, but the canonical service distribution protocol will be SOAP based.

· Unify connectivity protocols and communications interfaces end-to-end. Reduce the number of different access methods and protocols used inside the central complex. Use open, off-the-shelf protocols and systems. TCP/IP is the preferred connectivity protocol.

· Hide the complexity of the DBMS from the applications, users, and processes that access the data, by encapsulating these database accesses with service oriented APIs.

· Enable distributed data access with connectivity to heterogeneous DBMS within one unit of work.

· Avoid DBMS access across the wide area network. Propagate remote data queries via a service-oriented approach.

· Portals will deal with user sessions and presentation and will orchestrate the user interaction, including content presentation, but the business services will be provided by backend engines and will not reside in the front end portals.

· All systems to be adapted, built, or bought must provide the following features:

o Proactive and reactive monitoring capabilities

o Fault tolerant, load balancing, and fail-over capabilities

o Performance measurement, logging, and system health reporting

o Integration with system administration and management standards.

In addition, Category II Tenets are the natural realm for all SOA-related tenets. Those tenets deal with desired levels of service-granularity, SOA governance, SOA management approaches, etc. Because the grand theme of IT Transformation is the use of SOA, I will later cover these tenets in detail.

The Category III Tenets

These are the tenets that are defined at the departmental level. They describe naming conventions, documentation standards, reporting mechanisms, and pretty much anything dealing with the nitty-gritty of running a project and are therefore as important as the other categories. It is a good idea to keep a formalized track of how these tenets are defined, communicated, and enforced.

A typical challenge is that sometimes, tenets are created as Level III when in fact they ought to be vetted with a Level II scope. The opposite is also true. A sure sign of an organization trying to over-control a project is having Category II tenets that should be left to a subsidiary unit. Remember that allowing a degree of departmental freedom in choosing tenets at this level is actually a good way to ensure fluid dynamics and engagement of the base in the overall standardization process. In the end, you may have something akin to British Common-Law whereby Level III tenets become so widely adopted that in time they emerge as de-facto Level II tenets!

In my experience, developers tend to converge around novel tools that, due to their emerging nature, have not yet come onto the radar of the corporate bigwigs. Sometimes this results in conflicting viewpoints between the directives driven from the top and the preferred technologies driven from the grassroots. When thishappens you will need to open the floor to debate and be prepared to make some compromises.

An example of this situation is the manner in which TCP/IP was adopted as the preferred networking protocol. It is a fact that TCP/IP emerged from the grassroots, even as corporate directions coming from the top were trying to enforce the OSI or SNA protocol stacks. The ‘can-do-now’ and ‘can-do-cheaper’ pragmatism espoused by departmental gurus won over the ‘comprehensive’ and ‘structured’ OSI dogma espoused by the architects.

Because the OSI standard was a camel (i.e. a horse designed by committee), it was practically impossible to implement, and the grassroots’ preference for TCP/IP did turn out to be the right choice. To be fair, there are examples where grassroots-driven adoptions ended up being counter-productive. Take the wildfire adoption of the distributed Novel servers in the latter part of the eighties that ultimately led to the organic emergence of extremely complex environments; environments with a high degree of data heterogeneity and processes that companies had a hard time extricating themselves from. Now, I am not suggesting that the Novel corporation or its technology was at fault (after all, it was in fact a fairly leading technology for its time). Rather the issue was that much of the deployment of this technology happened pretty much ‘under-the-radar’. Most companies ended-up with duplicate data bases, data bases that lacked the necessary security, badly managed data, and in many instances, application code that was written for the very proprietary vendor environment and which could not be reused.

So what are examples of Category III tenets? The list can become fairly detailed and nuanced. I suggest breaking down these tenets into logical groups so that you have at least a means to compare and contrast tenets coming from different groups. The following groupings are recommended:

Data Tenets. Specific to the data, these tenets would include naming conventions, partitioning approaches, etc.

Foundational Tenets. Tenets dealing with system infrastructure and management would come here. Network IP standards, server naming standards, etc. would come here.

Presentation Tenets. These cover usability standards, use of presentation elements, navigation, etc.

SOA Tenets. XML tags, repository placement, service levels, etc.

General Tenets. Tenets dealing with general governance and project processes, including vender-selection strategies, evaluation and testing methods, etc..

Also, as a matter of fact, if you can also group the Category II Tenets along these lines, it would be a extremely useful way to ensure coherence between the Category III and Category II Tenet narratives.

That’s it. . . If you are “teneted-out” I don’t blame you. It’s time to dive into the Level II Architecture stage and, in particular, into SOA as the solution for that architecture level.