An Information Technology (IT) Architecture for ITD


DRAFT-August 1995


Gary Pirkola
University of Michigan
Information Technology Division
Technology Assessment Group

Table of Contents

Figures

Appendices



What is an IT Architecture?

The IT Architecture is an organized set of consensus decisions on policies & principles, services & common solutions, standards & guidelines as well as specific vendor products used by IT providers both inside and outside of ITD.

Thus one of the major activities associated with producing an IT architecture will be the process of achieving such consensus decisions. We understand that reaching consensus may constrain purchase and design options, hopefully in the interest of enhancing interoperability. It is a given that the greater the consensus achieved, the greater the organizational benefits attained.

What is the purpose of the IT Architecture?

The purpose of the IT architecture is to guide the process of acquiring, building, modifying, interfacing and deploying IT resources throughout the University.

As such the IT architecture should offer a means of stable evolution by identifying technologies that work together to satisfy the needs of the university users.

What are some of the key benefits of an IT Architecture?

What sort of framework do we see for the IT architecture?

A comprehensive view of an IT architecture specifies (1) policies and (2) principles that indicate direction, and (3) services and common solutions, (4) standards and guidelines, and (5) products that detail the means of implementation.

Thus our view of the framework for the IT architecture is that of a cube sliced into five sections or layers from back to front. Each section or layer represents a type of architectural specification from the most general IT policy layer at the back of the cube to the most specific product layer at the front of the cube. See Figure 0 .

Nonetheless there are relationships between the various layers. For example, many if not all of the services that institutions provide are guided by the man made policies of the institutions in which the services are provided. An institution like the University will have documented a number of these policies with information technology implications. Those policies are best implemented if some very basic information technology principles are adhered to. Continuing along the specification spectrum, one of the best way to insure that our information technology principles are adhered to, is to reach consensus on a set of standards and guidelines so that the products we buy or build will be architecturally consistent.

Where do we start?

The middle layer of architectural specification, the services and common solutions layer, is a good place to start getting a handle on the architecture. In our view of the framework for the IT architecture, it is most useful to take a distributed computing view of the services provided. By that we mean, we view most of the services and common solutions to be provided on the "server side" of the distributed computing spectrum with a well defined set of "middleware services" that allow services on the "client side" to interoperate. See Figure 1 .

More specifically our view of the services layer includes three levels of "server side services" from (3) the highest level application specific services like Administrative and Instructional applications which themselves make use of (2) the intermediate level common services and solutions like database management and information storage and retrieval services which themselves make use of (1) the lowest level infrastructure services on the server side like security (i.e. authentication and authorization).

The "middleware level of services" includes primarily the network support services, but also the associated interprocess communication services to support a distributed environment.

The "client side services" include (1) at the lowest level things like client operating systems and client side applications interoperability support, and (2) at the next level up, client applications like productivity software and database query and reporting tools.

See Figure 2.1 for a more complete depiction of some the distributed services that we see being provided at the various levels of the service layer of the IT architectural framework.

Detailing the Services

Once we have identified the distributed services to a working level of satisfaction, we can isolate and expand our effort by picking a particular service and detailing the sub services that make up that particular service.

For example when considering the E-Mail intermediate level "common solution" service, we need to be specific about the fact that we want the service to provide (1) both a directly connected and remote dial in service, in (2) both the LAN and backbone environments, with (3) gateways to other E-Mail services and (4) which provide (or more correctly make use of) both directory and authentication infrastructure services at the lowest level.

Moving out to other layers of specification

Continuing our example, having identified these sub-services for the E-Mail service, we can then proceed in either of two directions. Ultimately we want to do both.

We can "move towards the back layers " of our IT architectural framework, in the direction of being more general and identifying policies and principles that "provide direction" in the provision of E-Mail services. For example, policies like "electronic mail...(is) considered private to the fullest extent permitted by law." SPG 601.11. and principles like the E-mail package should provide a secure authentication mechanism or should provide access from multiple locations (the roving user).

Or we can "move towards the front layers" of our IT architectural framework becoming more implementation specific as we identify the standards and guidelines that are architecturally significant and the products that comply with these architecture standards. For example again using E-Mail as an example, some architecturally significant standards and guidelines are that the E-Mail service should use Kerberos for authentication or supports SMTP or that it conform to the MIME standard for "advanced content (multimedia) ". More importantly, it would be nice if we could even specify a product that adheres to our architectural policies and principles while conforming to the standards and guidelines that we've specified. Unfortunately in the case of E-Mail, a recommended product meeting all of our architectural criteria is not currently available.

Identifying the policies and principles that provide direction:

We think it's important to not attempt to completely identify all the IT principles and policies in a vacuum. Certainly we will have identified the policies and principles that have already been written down as part of the framework for the general IT architecture. We shouldn't be too concerned however if we haven't identified all of the relevant policies and principles for all of the service areas ahead of time. In fact it's much easier to think of policies and principles that are need to be in place in the context of specific services that we are or should be providing.

Identifying the "issues" needing architectural resolution

More important still is the process of identifying the "issues" needing architectural discussion and resolution in any particular service area. These are in fact the issues upon which consensus need to be reached before any agreement on standards and guideline or specific products for a particular services can be specified. In fact, it's quite likely that in the process of attempting to resolve these architectural issues we will revert back to (or possibly identify new) general architectural policies and principles that will help in the resolution.

An E- Mail example of an issue that has gotten resolved by referring back to the architectural policies and principles layer is the question of whether we should deploy any of the current LAN E-Mail solutions like MS-Mail or CC-Mail or Powertalk. The decision was no, and the (implicit) reasons are that from an architectural perspective, conformance to important IT principles like scalability, integration with UMCE infrastructure services (Kerberos authentication), and transparent remote access are all lacking in the current LAN E-Mail products.

It's also important to make sure we're focusing on architectural issues and not getting side tracked into other (e.g. operational) issues. For example, it's easy to say that one of the overriding principles is that we must provide reliable services. However reliability has both an architectural component and an operational component. We want to design our services architecturally so that we maximize reliability (by architecting redundant components when needed). However providing operational reliability (once architectural reliability has been designed in) is not an issue we will debate here. Operational reliability is generally a management issue and needs to be dealt with in that context.

Identifying the more implementation specific standards and guidelines as well as products

When thinking about the standards and guidelines layer of the framework it will be useful to identify first those services and common solutions for which we believe there is already consensus on the de facto standard or guideline and maybe even consensus on the de facto product. The sooner we get these easy pieces in place the sooner we will be able to start the consensus process on the harder standards and guidelines.

An example of a de facto standard or guideline that is already in place and agreed to is the use of the UM Uniqname and password and the Kerberos protocol for authentication. Here however an interesting question arises in terms of the specific recommendation.

It will be useful in many cases when recommending both standards and guidelines as well as products to identify both a current (tactical) recommendation and a target (strategic) direction and the plan for migrating services from one to the other. In the case of Kerberos, the consensus is that our current/tactical direction is to encourage the use of the UMCE's AFS based Kerberos V4 by all service providers, but that our target/strategic direction is to more to DCE Kerberos (V5) when it becomes available. The migration plan has been mapped out in a document produced by the IAA infrastructure service area.

Where do "whole products" and the "ITD Product Architecture" fit into this discussion of the technical architecture?

As ITD moves in the direction of providing "whole products that our customers will choose", it becomes increasingly important that ITD provides technical solutions that are developed and deployed in an architecturally consistent way across the organization and around the University. This is not only important for University wide interoperability, but also in order to provide a consistent user interface perspective, as well as from a cost/benefit perspective specifically when thinking about ITD maintenance and support efforts.

Very simply our view is that we can achieve this architectural consistency with our technical solutions if we are willing/able to use the component products from the first layer (the product layer) of our architectural framework to build the complete technical solution.

It should be noted however that the complete technical solution is only a part of the "whole product" that ITD needs to deliver to the customer. Our view is that the ITD Product Architecture is comprised of not only the technical services and related technical products mentioned above, but that there is another set of non-technical services (parallel to the technical services) at the middle layer of the architectural framework. Services like marketing, business processing re-engineering, data administration, software development, documentation, training, consulting operational support etc. that ITD needs to deliver which are themselves backed up by polices and principles in terms of direction and which are implemented according to standards and guidelines arrived at by consensus decisions. In this view of "whole products", the non-technical components at the product layer of the architectural framework (i.e. the things at the first layer) are the staff who model data and develop systems and provide consulting services and operate the production environment. Only when we begin to provide these non-technical services in standardized ways consistent with our IT policies and principles, will be begin to realize the true benefits of delivering whole products in an architecturally consistent way. See Figure 2.2 for a view of the non-technical services that ITD provides.

"Whole Products" and the "ITD Product Architecture" - The Data Access Whole Product as an example

Viewing access to administrative data (i.e. the Data Access Project) as a "whole product" is a good vehicle for discussing an ITD Product Architecture, not only the technical components but also the non-technical components of this whole product. The Data Access Project required UIS to think about providing a new set of services in a technologically different way. Moreover once the new technology was delivered, it was clear that a number of other non-technical services needed to be provided before this whole product could be considered a success.

If we think about data access as a whole product first from the technical perspective and start at the middle Services Layer of the architectural framework, there are a number of component services at a number of levels that make up the technical product. See Figure 3.3

At the highest level on the server side, we see that we are developing and delivering an administrative application whose primary responsibility/requirement is periodically taking authoritative institutional data out of the operational mainframe environment and depositing into a more readily accessible server environment that users can query and analyze. In order to accomplish that responsibility this administrative application will take advantage of a number of other technical services at other levels of the Service Layer.

The most obvious "common solution" at the intermediate level on the server side is that of database management. Moving across the client/server boundary and thinking about middleware services, the data access product will clearly need to make use of middleware interprocess communications software, specifically middleware software for client access to database services. On the client applications side of the Services Layer, the most obvious component is the database query and analysis tools that will be used on the clients workstation to access the institutional data. This tool needs to operate on the most commonly used desktop operating systems environments and to the extent that it is desirable that retrieved data be easily exchanged between other (productivity) applications on the desktop, an infrastructure service on the client side that provides such desktop interoperability is needed.

Finally before the client component of the product is able to use the database management component on the server side, a number of the lowest level infrastructure services on the server side will be invoked. Specifically some security services for authentication and authorization, a directory service to locate the institutional data of interest, possibly an accounting and billing service to charge and pay for the cost of accessing the data etc.

Having made a first pass at selecting the sub components of the services that will make up the technical product, it's useful to move back through the layers of the architectural framework to see what policies and principles might provide direction in the implementation of the technical side of this whole product. Looking at the Policy Layer of the architectural, see Figure 3.5 , we might note a policy that states that institutional data is a University resource that should be readily available to anyone with a need to know.

Similarly looking at the Principle Layer of the architectural framework, see Figure 3.4 , we might note that access to data should to be interoperable across multiple workstation and multiple data servers. Also that data should be able to be physically distributed across multiple servers.

With these directions in mind we can then move forward to the Standards and Guidelines Layer of the Architectural framework, see Figure 3.2 , and see what standards or guidelines might be in place for the services we have in mind. We note at the highest level on the server side that we are considering something commonly referred to as a "data warehouse". Unfortunately there aren't any standards for such things in general, so the way we get data out of the operational environment and into the data access environment will likely be quite proprietary. However to the extent that there is a reasonably all encompassing proprietary way to move data, we should standardize on this proprietary solution.

At the intermediate level of the Services Layer, we've standardized on the relational model and the SQL language as the way to store and access data. Likewise at the infrastructure level of server side Services Layer, we've standardized on Kerberos as our standard authentication service. Unfortunately we don't have any standardized authorization (i.e. access control) service as part of the infrastructure, so that service will need to be provided in a proprietary way by the database vendor's product. Standardizing on the middleware for data access is a technical component that is not here yet but not far off either. The ISO/RDA (Remote Data Access) international standards group is making good progress and database access vendors are actively committed to helping specify and then support the agreed upon data access protocol. Meanwhile using the proprietary database access middleware from one of the participating vendors seems a good tactical solution while we wait for the longer term strategic solution. On the client side, the most obvious standards and guidelines are the need to pick a query and analysis tools that accepts SQL, and supports the middleware API. In terms of standards for exchange of data between tools on the desktop, a number of vendors are backing OpenDoc as a de facto standards.

As concerns the Product Layer of the Architectural Framework, see Figure 3.1 , we have selected a number of products, some conforming to de facto and de jure standards and some very proprietary component solutions. Our relational database of choice institutional wide is Oracle. As mentioned Kerberos V4 is our tactical authentication solution currently, We use Oracle's SQL*Net as the proprietary middleware. Anadyn's GQL is the query tool that is portable across Mac and PC platforms. It allows exchange of data between other productivity tools like Excel on Mac and PC platforms, and supports SQL*Net as the API for client data access to the server.

A few words about the non-technical aspects of the Data Access "whole product"

We have not spent much time and effort mapping out the details of the services, standards, and products on the non-technical side of the architectural framework. In fact we view this activity as one of the primary (and hopefully first) activities of the newly appointed Product Area Managers (PAM's) in the recently re-organized Product Development & Deployment (PD&D) group. Nonetheless, we believe it useful to "run through" the Data Access whole product example to see how the proposed architectural framework might provide direction and indicate implementation options on the non-technical side.

Looking at the non-technical services that needed to be provided to implement that Data Access whole product, some of the things that come to mind are:

(1) marketing - the need to understand exactly what users want to do with these snapshots of the operational data (i.e. identifying a need and then working with interested users to better understand the specifics)

(2) data administration - the need to model and standardize the data so that it can be related to other data from other sources

(3) training/documentation/consulting - the need to educate users so that they will use the data effectively and have somewhere to go with their questions.

(4) operational/production support - The product that we are providing must be available, reliable, etc.

Having detailed some of the specific non-technical services that needed to be provided as part of the data access project, it worthwhile to move towards the back of our architectural framework and see what sorts of policies and principles might be in place that provided direction for this whole product. Moreover it would be desirable if the relevant policies and principles were independent of whether the services were technical or non-technical in nature. Looking at the Policies Layer of the architectural ( see Figure 3.5 ), we might note that the requirement that all institutional data will be modeled, certainly provides direction for the data administration services that ITD provides. Moreover the policy that the privacy and integrity of data will be maintained has non-technical aspects as well. Looking at the Principle Layer of the architectural Framework ( see Figure 3.4), we note that the principle of involving users in the design, development and deployment of our products is the basis for the heavy involvement of the ultimate users of the data in the pre deployment stages of the data access project.

As we look forward in our architectural framework to the standards and guidelines that might help us implement the non-technical services, we immediately make note of the fact that there is a set of data administration guidelines produced by the data administration group that defines for example what institutional data is sensitive and thus requires more security than normal. The data administration guidelines also roles and responsibilities for data stewards so that decisions about who may access specific data can be dealt with. Finally the data administration guidelines define data naming standards so that data may be easily shared no matter what the operation source naming conventions might be.

As mentioned earlier the lowest layer of the architectural framework, the Product Layer is simply the staff that implements all of the non-technical services described according to the standards and guidelines indicated via the direction provided by the architectural policies and principles. It is useful to note however that in the early stages of the Data Access project, many new staffing decisions needed to be made to "ramp up" the support for the newly defined services being provided. Services like DBA's for Oracle, systems support for AIX on the RS6000's. In addition, many existing staff responsibilities were redefined to include many of the new services that needed to be provided. Responsibilities for training new users in the use of the data access environment, etc.

What have we produced for the first phase of the architectural effort?

We have produced we believe a rather complete overview of the IT Architectural Framework (see above) which not only describes the different layers of architectural specification, i.e. policy, principle, services, standards, products, but also describes, the middle level of specification, the services layer, in enough detail so as to give a sense for the technical services which the architecture will address. Examples of particular service areas, e.g. E-Mail, have been used to indicate the types of specification we expect to be detailed at each layer of the architecture.

In addition, an indication has been given of the parallel layers of a proposed IT non-technical architecture, as well as details of some of the types of services that are provided at the non-technical middle layer of specification. Finally an indication has been given of how both the IT technical and non-technical architectural specifications will allow the definition of an ITD Product Architecture that will be use in the development and deployment of "whole products" within ITD.

The assumption is that institutional policies that have IT implications, and to a lessor extent IT principles, will be independent and equally applicable to both the technical and non-technical service areas. That is to say, as we articulate the policy and principle layers of the architectural specification, we should try where possible to specify principles that not only are independent of technical or non-technical service areas, but in fact are applicable to both. To the extent that we are able to do that, we will be articulating basic IT policies and principles that will help us make consistent architectural decisions across the technical and non-technical service areas.

Appendix A details a first draft of some of the more general IT policies (or values or attitudes) that have IT architectural implications here at the University. Appendix B details a first draft of some of the more general IT principles that are service area independent and we believe define the basic goals or design objectives of the IT architecture. Neither of these lists should be viewed as complete and these policies and principles listed in the appendix are intended to be more general and IT wide than the specific policies and principles that shape the architecture for any specific service area. Finally, Appendix C contains a more complete first draft of the middle layer of technical services (common solutions/processes) provided by ITD.

What still needs to be done for phase two of the architectural effort?

Producing the details of the architectural specifications for each of the technical and non-technical service areas is clearly the next step.

Having identified many (but certainly not all) of the service areas in the middle layer of the technical and non-technical architectural framework, we have selected a number of the service areas that we are either familiar with ourselves (e.g. data/information, administrative applications, interprocess communication, client application interoperation), or service areas that are well documented (e.g. E-Mail, or security), or service areas where we have had detailed conversations with the experts within ITD (e.g. networking, directory services) and have produced a first cut at a more complete architectural specification for those selected service areas.

The purpose in our attempting this first crack at some of the pieces of the next phase of the effort is twofold. First we wanted to see whether we could produce a set of detailed specifications that both followed the layered approach of the architectural framework and produced information that addressed the architectural needs of the specific service area. Second we wanted to have a few templates in place so that as we got other people involved in the definition and documentation of the detailed architecture, we would have something they could look at and pattern after.

Thus, following the Figures and Appendices, are drafts of the detailed architectural specifications for selected service areas. Note that each of the detailed architectural specifications is laid out in a standard way where first we define the service area and any discussion that might be useful, then indicates the policies and principles that provide architectural direction for that service area. A list of the important architectural issues that require consensus and resolution are then detailed, and finally tactical and strategic implementation directions are proposed that are consistent with the standards and guidelines for this service area and the products currently available or projected to be available in the near distant future.

In some of the more well defined and well specified areas like E-Mail, after specifying the policies and principles that are specific to this service area, we have indicated a need to detail many of the sub-services provided by this general service area. After specifying the standards and guidelines that we feel are either the de facto or de jure standards for each of these sub-services, we then indicate the recommended products that conform to these standards that are currently in use in ITD and around the University (and for which there is hopefully already consensus agreement). An important characteristic of many of these service area (e.g. E-Mail and networking) is that there is a well defined group that has ultimate architectural responsibility for this area, and thus the role of any follow-on ITD architecture activity would be simply to facilitate discussion of new architectural options and to make sure the existing architectural specifications are well documented and available to the rest of the IT community.

In other areas things are not nearly so straight forward or well defined (e.g. directory services and security). Here although we may conceptually agree on the standards and guidelines for these service areas (i.e. X.500, and Kerberos), there are a number of players that do not (and maybe cannot) easily conform to the implicit standard (e.g. the lack of standardization for the various LAN directory and authentication services). In these cases it's more important to identify the architectural issues, the relevant players, and some possible scenarios for how these service areas might become more standards conforming over the long run. Here the role of any follow-on ITD architecture effort would be to facilitate discussion about long term strategic plans and the resultant short term tactical plans for converging toward the desired architectural guidelines.

Finally there are service areas where there may not even be agreement yet on what the tactical or strategic direction should be, and it's not at all clear who the appropriate players are, or maybe even what all the options or even issues are (e.g. the interprocess communications service area with DCE/RPC and/or CORBA as two potentially conflicting options). In this case the major work required of any follow-on ITD architectural effort would be to get the appropriate parties together, verify and/or document all the options and the associated architectural issues and then see if consensus can be reached on either tactical and/or strategic direction.

In all of the above cases where we have become reasonably knowledgeable in a particular service area, we have provided a first draft of what we believe to be the relevant architectural principles, standards and guidelines, options and issues in anticipation of the need for further discussion and consensus by the follow-on phase of the architectural effort.

Note that there are some service areas (Instructional Applications, Computing and Statistical Services) where our prior knowledge or the information available to us is of such limited utility that we have made no attempt to detail the specifications of those service areas. In these areas the responsibility of the follow-on architecture effort will be to first identify the appropriate group or collection of people who need to assume responsibility for this service area, and then to facilitate a consensus building process for "producing" a draft set of architectural specifications for the service area in question.

What should be the overall goals of the follow-on ITD architecture effort?

Clearly there will be an on-going architectural effort within ITD for sometime to come as we attempt to converge on a set of standards and guidelines that will make our whole products more consistent and interoperable. We need to indicate a set of priorities for the various service areas so that the areas where reaching consensus on the architectural specifications will lead to the greatest benefit in the shortest amount of time are the ones we address first. This prioritization should take into consideration some sense of the needs of current ITD and UM projects. Instead of trying to lay out a complete master plan for the architecture, which may in fact not even be possible given the rapidly changing technology with which we are dealing, a sense for what areas and issues need resolution most needs to be obtained from those attempting to develop solutions, and those areas need to be addressed first.

Certainly filling in the details of the architectural framework in some priority order is the desired result, but the process by which this happens and the requisite skills of the participants are probably even more critical. The first thing to note is that one of the most important skill to bring to the table is that of facilitating the building of consensus among the appropriate participants as to the principles, standards, guidelines and ultimately products in the highest priority service areas. Detailed technical expertise is not sufficient, and may not even be mandatory among those acting in this facilitation role .

More important is the ability to assemble the right group of people, most of whom do possess the technical expertise. Being able to clearly document the architectural principles of importance in a particular service area, being able to identify the architectural issues that are in need of resolution, understanding where evolving standards are heading and the extent to which such various standards are important in the university environment, and finally being able to facilitate the building of consensus among a diverse group of participants so that the institution benefits in the long run, are all important skills and responsibilities that those responsible for the follow-on ITD architecture effort needs to embrace.

It goes without saying that once architectural consensus is reached, disseminating information, educating staff and deploying mechanisms for compliance are all important activities that will enhance successful implementation of the architecture. Clearly this will require working closely with the other parts of ITD that have ultimate responsibility for building or buying IT solutions for the rest of the University.