IT Transformation with SOA

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.

Labels: Architecture, categories, IT Transformation Defined, Open Source, rchitecture, SOA, Tenets

posted by IT Transformation with SOA @ 1:16 PM

The Architecture Reference Model

Let’s say you are a clothing designer competing on an episode of Project Runway (I reluctantly confess to be a fan of this show), and are asked to design a man’s suit. Chances are you will design it according to the desired needs and characteristics: winter or summer, business or black-tie, silk or wool fabric, etc. Also, you’ll likely incorporate your own particular professional touches even as you use pre-built suit patterns to tailor it.

For the most part, despite the range of variations that can be expected in the design, chances are that when creating a typical western suit you will end up with a pair of pants and a jacket; not a Scottish kilt or a clown outfit.

Fundamentally, architecture models are no different. When solving a similar business problem, most architecture models will end up looking similar to each other regardless of the vertical industry to which they apply. For instance, the architecture model for a high transaction airline reservation system is going to be very similar to the architecture model for a high transaction banking system, and indeed, these verticals share many of the same technologies. The phenomenon of “convergent evolution” also applies to architectures. Whenever nature requires a solution to a specific problem, evolution tends to arrive at an analogous solution for survival challenges. For instance, it is known that the eye has been arrived at independent by different animal species (the eyes of insects, octopi, and humans are different) and the flight of bats is an independent result of the flight of birds.

But even if most architecture models will resemble each other, as the saying goes: “the devil is in the details.” It will not suffice to copy a model from a textbook and brand it as the definite model for your company. At a minimum, your model must meet these characteristics:

§ It must be Realistic. No matter how abstract a model, it should ultimately be implementable. Also, the term “realistic” here means that the model should apply to the specifics of your company.

§ It must be Mutually Exclusive and Collectively Exhaustible. This is a fancy way of saying that it should be complete but also economical in its definition—without overlaps and without gaps. Unlike actual implementation designs, which I believe should be slightly redundant and overlapping, reference models can strive for Platonic-like perfection.

§ It will clearly describe its key areas as inter-related, decoupled modules. In today’s terms this means that it should be SOA-friendly. Even though, we are still at Level I, and SOA will be formally introduced on Level II, we know already that unless you are architecting something extremely unique and with a very specialized domain as, for example, software for biomedical devices or for games, SOA is the way to go.

The actual Architecture Model will probably be a brief reference document outlining in narrative form the key concepts of the model: components, key technologies, interaction maps, component inter-dependencies, etc. Remember, we are still in Level I, at the hundred-thousand foot level.

The next step is to represent the architecture model via a highly iconic diagram that incorporates all the key elements of the logical architecture as well as representation of the architecture mapping the business processes. I call this diagram the Architecture Reference Model (ARM), and this diagram is destined to become the friendly-face of the Architecture Model you will document. The ARM is to become both your banner in all subsequent architecture socialization efforts. It serves multiple purposes:

§ Synthesizes in a single chart the key architecture elements and messages you wish to convey

§ Serves as a communications icon, identifying the focus of your technology team.

§ It becomes the rallying flag for all your technology design efforts. It gives a point of reference to help the project team place into context the various detailed efforts.

The ARM should be not so detailed that it drowns in complexity; nor so high level and so generic that it could apply as the architecture reference model for just about anything. If your ARM could apply to the coffeehouse across the street, it is likely too generic. The ARM should include substantial content.

The ARM should be visually appealing and compelling. Enlist the services of a professional graphic designer, if necessary. Remember you’re looking for the ultimate iconic point of reference to summarize all your technology design efforts.

Initially, expect the ARM to change fluidly as you receive feedback from the initial drafts, and as you become more assured of the specific architecture representations. After a few revisions, however, the ARM should become more stable. This is not to say that it will never change, but if you’ve developed a properly designed architecture framework model diagram, adding elements to it should not require extreme changes to the core graphic.

The ARM shown below is based on an ARM designed for an innovative hospitality solutions company, and it is reproduced here with their appreciated consent (AltiusPAR Hospitality Solutions—www.altiuspar.com). What should become immediately apparent is that, even though the diagram was initially created for a specific type of industry (Hospitality), it could easily be applied to other industries. Admittedly, I deliberately used generic terms (e.g. Customers instead of Guests), but tailoring and narrowing the specification of this diagram to other industries would be relatively simple.

See how the ARM above visually highlights the following specific aspects of the proposed architecture model:

· External users (Merchants, Web, and Business-to-Business) will be handled via an external access layer.

· The Intranet and internal customer support systems will be placed inside the DMZ.

· All users access the SOA layer to obtain Shopping, Content, and other Services

· The Data Bases are “hidden” from the service users by the service layer.

· Subsystems such as Campaign Management, Sales Support, Loyalty, etc. must support the external and Intranet users and be accessible from regional systems (presented at the bottom of the cylinder)

· You will be providing Publish/Subscribe services to the field offices, which will only be able to access the core system via VPN

· There will be support and management systems for all layers in the hierarchy

The list could go on and on. A good ARM is a little like a good painting whereby, the more you inspect it, the more information you can gather from it. Don’t underestimate the importance of achieving an ARM that can convey all key architecture model aspects in a single diagram. The intrinsic value it provides by focusing the transformation project framework is invaluable. Besides, it will make for a great poster for your office wall!

Labels: Architecture Model, Architecture Reference, IT Transformation Defined, SOA, Transformation

posted by IT Transformation with SOA @ 12:37 PM