I0016

January 21, 2001, The EWITA newsletter

Welcome to the latest issue of the Enterprise-Wide IT Architecture Newsletter!

Supporting the Enterprise-Wide IT Architecture (EWITA) web site at http://www.ewita.com/

Prior newsletters <here>

------------------------------------------------------

Announcement:

I have changed the default for the mail list to deliver once a day, this will reduce your email, when (if) I goof up the messages again. Those of you that requested other than daily summaries were left alone.

------------------------------------------------------

Help a student complete his dissertation project at Nova Southeastern University buy completing a survey, information here

------------------------------------------------------

Table of Contents

Editorial
Hammering away in the garage

Application Architecture Design Principles and Best Practices

Site Spotlight

Tennessee's Information Resources Technical Architecture

Recommend a site to be reviewed.

Vendor Spotlight

elance

Vendors, here is a chance to reach a selected audience of technical architects, send information to EWITA.

Feedback

Responses to your comments and questions

------------------------------------------------------

Hammering away in the garage

Introduction

In the Meta process as well as many other Architecture processes, a major part of the process is the development of Design Principles and Best Practices, in the last issue the article was about Security Principles and Best Practices. This issue the article is about those Principles and Best Practices used in the Application Architecture of the Employment Development Department of the State of California.

These Practices and Principles are not all inclusive, but were used in the development of the Business Driven architecture for that organization. They could be used as a basis for a development document for any large organization, or in a discussion group to get the group to begin thinking in a Enterprise mode.

Another example of Design Principles are located on the EWITA site in the Tools area (straw Dogs or you can directly navigate there by clicking here http://www.lanset.com/dmcafee/EWITA Tools/Strawdogs/SD Principles.doc.

Application Architecture Principles and Best Practices

Applications encompass the purchase, development, enhancement, maintenance, delivery and support of business application software within the Organization. Applications run on systems, access data and deliver services through communication networks.

The Application Domain defines how applications are architected, how they cooperate, and where they reside. A effective application architecture enables:

Rapid response to business process change

Reuse of software components

Rapid deployment of applications

Enterprise wide system integration and support.

Design Principles

Definition: Statements agreed to by the enterprise that direct the selection, acquisition, deployment and management of technology.

Area
Design Principles

General

The Enterprise will adhere to the application architecture policies and standards.

The Enterprise’s enterprise architecture will define a consistent set of application development and testing tools.

The Enterprise’s application architecture will be integrated and supported.

Application development is a collaborative effort between centralized IT (CIT) and distributed IT (DIT). CIT is responsible for enterprise applications or when they are chosen as the provider of choice. DIT is responsible when the effort is specific to their business.

The CIT is responsible for production integrity, reliability, performance, security, backup and recovery and, therefore, has approval or disapproval authority for deployment of production application software in the Enterprise.

Applications must meet production standards prior to deployment in the production environment.

The IT outsourcing contracts will be reviewed, prior to contract approval, by CIT for the purpose of architecture compliance.

Application Development

All application development tools must be Year 2000 compliant.

Develop applications to meet customer defined criteria for ease of learning, use and support.

Design applications to provide a consistent look and feel to users by utilizing Department and industry standards.

Build reusable components to be shared across the enterprise whenever possible.

Code applications for ease of development and maintenance.

Utilize a web browser for the application interface when appropriate.

Support communication between systems using middleware.

Use asynchronous communications whenever possible to increase performance and scalability.

Evaluate components based upon the "proven" criteria, where "proven" is defined as:

Baseline use in EDD (i.e., has a track record)

Enterprise scalability

Fiscal solvency of vendor

Future product growth potential

Installed development base

Length of time in the market

Programmer productivity

Support available

Support through in existence contracts

Taught in region

Support of market leading and industry accepted standards.

Design systems that facilitate the reuse of components across the enterprise.

Establish a reuse methodology for the identification and implementation of components.

Establish a component review board to identify common components.

Establish component design reviews of all ongoing projects.

Establish a repository for maintaining the information about available reusable components. The repository provides a place to store documentation about the component API’s.

Assign ownership and maintenance responsibilities of components.

Publish an application program interface (API) with every component.

Harvest components from existing applications to build the component repository.

Implement one business rule or function, or a small set of related business rules or functions, per component.

Develop reusable testing suites for every component.

A component testing suite contains special programs needed for calling a component, as well as sample input and output data for verifying results.

Adopt effective component management methodologies, including the tools to support component reuse.

Design component services to be callable by any application or any other component.

Design new components to be platform independent.

Purchase rather than build components whenever possible.

Design components to be fully self contained.

Minimize the number of languages used for application development.

Support all approved languages with established training programs.

Minimize the number of tools used for application development.

Support all approved application development tools with established training programs.

Minimize the number of application development support tools.

Middleware

Use middleware to facilitate reuse and shorten development cycles.

Use middleware in heterogeneous, distributed computing environment.

Middleware solutions must be scaleable to support increasing numbers of users without decreasing performance.

Middleware solutions must support logging where applicable.

Document application interfaces to facilitate reuse.

Centrally manage enterprise-wide middleware as part of the strategic infrastructure.

Ensure enterprise-wide middleware products are independent of code development tools where possible and practical.

Use open standards and protocols rather than proprietary for inter-component communication.

Must be scaleable to support increasing numbers of users with minimal performance decreases.

Componentization and Communication Models

Use open standards and protocols rather than proprietary for inter-component communication.

Design enterprise applications to use asynchronous communication when an online application does not require an immediate response and/or updates can be processed out of sequence.

Session Workflow / Transaction Control

When distributed transactional integrity is needed, use transactional middleware for online transaction processing (OLTP) rather than the transaction management capability of a database management system (i.e. stored procedures).

Enterprise transactional middleware must support ACID (atomicity, consistency, isolation, durability) transactional properties.

Enterprise transactional middleware should support delegated commits for transactions.

Use MOM products for applications that utilize an asynchronous communications model.

Data and Legacy System Access Products

Use best of breed gateways to provide access to a specific product / system rather than a "universal" gateway product that tries to provide access to multiple systems (e.g. IBM DB2 Gateway rather than a single DB2 / Oracle / Sybase / IDMS / CICS / VSAM / MVS access product).

Use a single gateway product enterprise wide for access to an individual backend system.

Use Database Gateways that use standard, open APIs such as ODBC and JDBC.

Internet/Intranet

Select mainstream tools based on business needs and business required volume.

Design systems to ensure the maximum reliability and performance.

Test systems to ensure the maximum reliability and performance.

Choose standards that are open, pervasive and non-proprietary, whenever possible.

Design systems to ensure secure access based on business needs.

Design systems to ensure secure data transport based on business needs.

Design applications to be portable across server platforms identified in the Enterprise Architecture (EA).

Design applications considering the end user’s available bandwidth.

Present information in a format appropriate to the user community.

Design applications according to Marketing and Constituent Services (MACS) EDD Internet home page’s content, format, and presentation design guidelines.

Browser

Present information in a format appropriate to the user community.

Use commercially available browsers rather than building a functionally equivalent product.

Minimize the number of supported browsers (vendors and versions).

Design Intranet applications to take advantage of features provided by the standard browser.

Server Software

Assign and configure Internet/Intranet servers based on function.

Use a standard Application Programming Interfaces (APIs).

Use software that supports the Infrastructure Domain/Systems Management Component of the EA

Use standard security protocols as identified in the Security Domain.

Support logging for diagnostic and user tracking purposes.

Search Engines

Minimize the number of searches required to locate information throughout the enterprise (Intranet Only).

Searches of the Internet application will be provided by any of the commercially available search engines on the net.

Publicize site to major search engines to assist commercial search engines in finding the site.

Authoring Tools

Training must be available for all tools selected (e.g., classes, books, videos, CDs).

Scales to the needs of the users.

Groupware

Groupware requires a consistent infrastructure and communications backbone in order to support collaboration and communication.

Facilitate real time access to information from any location.

Implement single instances of groupware technologies whenever and wherever possible.

Plan for adaptability to accommodate future changes in the environment.

All products must be thoroughly tested prior to implementation at EDD.

Groupware software will automatically update and organize the material whenever users connect their personal computers or workstations to the network.

Content Exchange

Must support document exchange with non-department users and applications.

Utilize standard mainstream exchange protocols.

Electronic Mail (E-mail)

Administer E-mail servers as a part of the strategic infrastructure.

Implement E-mail servers that support multiple standards based E-mail clients, (i.e., Exchange, Outlook, SMTP).

Utilize a common E-mail directory service throughout the organization.

Implement E-mail clients that have standard APIs for E-mail-enabling other applications.

Implement security for E-mail message transport and storage.

Minimize gateways with the aim of eliminating them entirely.

Calendaring and Scheduling (C&S)

Implement a C&S application that maintains transparent interoperability with other C&S applications and computing platforms (Open Standards).

Implement a C&S application that provides a mechanism for attaching meeting materials or supporting documentation to the notification message.

Implement a C&S application that allows the user to create both public and private notification groups and contact lists.

Implement a C&S application that enables task and resource management.

Implement a C&S application that can be accessed through a web front-end.

Electronic Document Management System (EDMS)

Utilize system with capability of storing and retrieving documents in native format.

Allows the viewing or retrieval of a document in native format.

Must be part of an existing security system, must not have it's own security services.

Workflow

Business processes must be validated and/or engineered before implementing workflow processes.

Desktop Publishing

Ensure desktop publishing is consistent with the enterprise print organization..

Best Practices

The application domain best practices extend across both object and non-object development and are divided into two categories: the first category, General Best Practices, applies to all applications; the second category, Strategic, applies more to client/server, distributed and network computing applications.

Best Practice

Rationale:

Select application development languages from the list of approved languages contained in the application development component.

Leverages internal and industry trained IT staff.

Maximizes range of support tools available.

Enhances maintainability.

Increases likelihood language will be used and available in the future.

Utilize mainstream technology to ensure that systems are designed and built with products and technology that will be widely supported into the future. Consider application development tools based on IT research sources such as Gartner Group and META Group.

Based on a consistent set of criteria covering:

Ability to execute

Completeness of vision

Research and analysis cover all segments of the IT industry

Industry views are updated on an ongoing basis

Leverages internal and industry trained staff

Maximize range of available support tools.

Separate online transaction processing (OLTP) from decision support services (DSS) and online analytical processing (OLAP).

Information can be produced without impacting the performance of OLTP systems.

Growth in OLTP is incremental and requirements are predictable. Growth in DSS and OLAP has been non-linear and requirements are difficult to predict.

OLTP allows the customer to do their business, it is operational; decision support allows the customer to manage their business, it is strategic and tactical.

Use a data warehouse(s) to accelerate decision making and reduce the development burden

Much of the development that occurs in OLTP systems supports decision support and analytical processes. Moving these functions to a data warehouse environment stabilizes the OLTP systems and provides greater accessibility and scalability to meet decision support needs.

Ad hoc data requests can be fulfilled quickly.

Decision makers need access to information and the tools and skills to utilize that information to the greatest advantage.

Supports more mature and advanced data analysis and reporting tools.

Customized development should only occur when critical business needs cannot be met by commercial applications.

Business functions (e.g., attendance and travel) common to all businesses can be provided by software vendors at a lower cost than customized development.

Staff use standard systems and processes for administrative functions; therefore, training and skills are leveraged.

Reduce TCO for the enterprise.

Follow a Total Cost of Ownership (TCO)

Methodology to achieve the lowest aggregate cost to the Enterprise.

Leverages core competencies, skill sets, and tools.

Leverages and utilizes proven products.

Lowers total enterprise costs.

Decreases range of products.

Evaluates a product or technology over its entire life cycle.

Provide adequate training programs to ensure application developers are highly skilled in identified application development languages and tools.

Enables the enterprise to leverage trained development staff.

Emphasize the use of standards and best practices to reduce integration complexity.

Enables the enterprise to focus staff resources.

Reduces required skill sets.

Facilitates a consistent look and feel across applications.

Leverages staff training and skills.

Application delivery should be evolving towards an object-oriented approach.

Facilitates reuse.

Facilitates ease of maintenance.

Facilitates N-tier development and the migration to N-tier development.

Reduces application complexity.

Document applications in a repository.

Facilitates reuse.

Facilitates ease of maintenance.

Strategic N-tier Best Practices

Plan for scalability and increased functionality in applications and systems.

The Enterprise will continue to experience rapid change in business processes; therefore, the applications supporting these processes must be able to adapt and respond quickly.

Most systems and applications evolve to support new business requirements.

Develop applications that are "highly cohesive" and "loosely coupled." A highly cohesive application is one that implements one business function (e.g., print check) and is invoked for one purpose. Loosely coupled applications can accomplish a task without requiring or waiting for a response from another application.

High cohesiveness enables reuse and sharing of common application business rules.

Loose coupling allows applications to operate independently.

Design applications to leverage continuing changes and improvements in technology.

Enhances ease of maintenance.

Reduces time to change/repair code.

Build applications and systems to use modular, shareable and reusable components.

Facilitates ease of development and maintenance.

Duplicate functionality in multiple systems can create redundant and inconsistent results. This requires additional reconciliation processes, which add complexity and inflexibility to the architecture. The architecture will clearly define where functionality will reside and how systems will share data and business logic.

Leverages department resources so as not to "reinvent the wheel." Application code can be written once and reused whenever feasible.

Applications can be built by assembling and integrating existing components, rather than by always creating custom code.

Shrinking cycle times do not allow for artisan programming.

Implement business rules as discrete executable components or services.

Isolates the business rule from changes in the user interface and data access logic.

Layer strategic application systems using an N-tier client/server model.

The Enterprise will continue to experience rapid change in business processes; therefore, the applications supporting these processes must be able to adapt and respond quickly. N-tier client/server architecture is the most flexible and scaleable of the existing architectures.

Allows applications and data to be designed for enterprise use and not just for a single business process.

N-tier applications are easily modified to support changes in business rules.

N-tier applications are highly scaleable.

Any combination of user interfaces (e.g., character, graphical, web browser, and telephone interfaces) may be implemented in an N-tier application.

Business units are responsible for defining and maintaining the integrity of business rules.

The business units are best positioned to be responsible for the definition and integrity of business rules, and for communicating changes in business rules to IT.

Every business rule should have an assigned custodian in the business unit.

Document the implementation of all business rules.

Establishes a common language and facilitates communication between business units and IT.

Documentation practices support both business and IT organizations.

Ensures that all business rules are implemented.

Allows discussion between users to ensure completeness of business rules.

Architect systems to be business event driven rather than process or data driven.

Business events represent the essential activities of the business and are easy for business users to understand, identify, and verify.

The closer the system is to business operations the easier it is to identify where changes must occur when the business event changes.

The business events that a system captures and responds to clearly define the boundaries of a system.

Install server resident business rules to improve performance, reduce software distribution complexity and increase reuse.

Server based business rule applications enable reuse and sharing of the business application logic across the enterprise.

Business rules update shared data; the update logic used must be consistent from application to application.

Partition applications so business rules control access to data.

Data is created and used by business processes. In computer applications, data must be created, used by, and managed by the application component that automates the business process.

Accessing data in any way other than by business process bypasses the rules of the module that controls the data.

Write departmental, mission critical business rules in a non-proprietary language.

Maximize software reuse.

Maximizes application portability.

Leverages internal and industry trained programming staff.

BTW: A question for those of you that have read to this point. Could a small organization have a architecture using only Best Practices and a Buy List? Or, what kind of architecture could a small organization have at a minimal expense?

Send any question, message, article or white paper to me, directly at dmcafee@ewita.com or the community address of EWIT_Architecture@egroups.com.

<top>

------------------------------------------------------

Site Spotlight

Tennessee's Information Resources Technical Architecture

This site is "a framework of established standards, guidelines, and directional statements to be used in the management of information resources in the State". Covering Architecture, Hardware/Software, Communications, Web infrastructure, Standards and a Data Warehouse Architecture, the site offers the user who are the IT staff and IT vendors for the State of Tennessee a good view of what is required for a state-wide application or implementation.

The technical architecture is a mere 10 pages long but does get the necessary information communicated, including those hardware and software products that can be purchased. Some parts of the site are restricted and you must request access, and example is the Data Warehouse Architecture.

The site has many interesting and useful charts and illustrations.

I like the tight integration of the standards site with the Architecture site, it is nearly seamless! This is a very good example of a framework architecture for a state agency.

The site is easy to navigate and to find information. Written in non-technical, jargon light terms the site allows even the novice user to click directly to the area of interest. An example is "The Department of Finance and Administration Office of Contracts Review (OCR) must approve the final draft of every RFP prior to its release. Department of Finance and Administration approval will be contingent upon Comptroller approval of the RFP." Which is found in the standards area. By jargon light, the above sentence indicates a RFP where a novice might have to refer to the sites Glossary for what a RFP is. The site uses a lot of white space, not cluttering the screen with dense text.

Got a good site that you would like to have spot lighted?

Send any recommendations to me, directly at dmcafee@ewita.com or the community address of EWIT_Architecture@egroups.com.

<top>

------------------------------------------------------

Vendor Spotlight

elance

I had the privilege of working with you on the SOC E-Gov Arch Task Force and am fan of your architectural news letters. Thanks for providing this great service! I have ran across an Website that might be of interest to Architectural Free Lancers out there looking for various work opportunities. Signup is free and it appears to be a useful site. It is located at URL http://www.findfreelance.com/ and I would appreciate some feedback from a senior consultant like you as to your first impression.

Regards, ED Carter Ecarter@HHSDC.CA.GOV

Response:

The site appears to be oriented toward small business and those individuals who can provide services. I think the concept is very good. A customer describes the project, in a particular work classification, and "freelancers" (developers) can browse and bid on the work. Also a customer can take a look at a group of individuals who provide a type of service. It is a fun site to browse, to compare what you might bid given the information on the site. I looked for "architecture" type of work, but the jobs described were more "in the trenches" based on an existing architecture.

If it was my site, I would have a tracker mechanism that would take the job classifications and notify by email the based on the developer’s selection, when a request for bid (RFB) was entered. That would allow shorter RFB times and a wider variety of bids.

I think that this type of site will become more common, and will be adopted to some extent by most government agencies as the staffing and retention problems increase in the field. I can see this tied into the "GSA" type of procurement where bidders are pre-qualified, and a government agencies post to a similar site. Of course, being government, there will be some limits on the dollar amount of the bids.

From the site:

eLance is the leading professional services marketplace and end-to-end platform for web-based projects used by businesses worldwide. Buyers tap into a highly qualified pool of professional talent and get a wide range of projects completed online -- including software development, web design, creative services, research, translation, copywriting and more. Service professionals find a global market for their services, and build their reputation through the feedback rating system. Online collaboration tools include a global billing and payment system, Work Space file sharing, and quality guarantee programs designed to maintain high standards of satisfaction.

Comments:

The site shows what I think is an example of "Things to come", i.e. because of staffing resources, outsourcing of a lot of the development work for the day to day development. The site is like a reverse auction for services, a company can post a piece of work and request bids. Similar to a Request for Services but it appears most of the requests are of short duration and low cost. If you were a large complex site, it would pay to have a comprehensive architecture developed before you started using this site. I would spend a few minutes and review the site, if not to place a bid, just to see how the site might be used for those pesky one off jobs like a reference web site or conversion of a data.

Got a good site that you would like to have spot lighted?

Send any recommendations to me, directly at dmcafee@ewita.com or the community address of EWIT_Architecture@egroups.com.

<top>

------------------------------------------------------

Editorial - Damn it I got another headache

Seems that the issue coincide with parties. My daughter had a birthday party for my wife last night and now I'm supposed to come up with an editorial and some sage advice. Well here it is - Don't sample 21 cheap wines trying to find a good one. I don't care what you do with the wine, you still have a hard time thinking the next day! Sorry about that.

This news letter and site would be a lot better if you would donate a article, or a opinion or a presentation to the EWITA site, of course you get the credit for it. So what would be welcome, since Technical Architecture covers most anything having to do with computers, you probably have a lot of hidden resources hidden on your C drive. A white paper, or in-depth memo about some process or procedure might make good fodder for the newsletter. Remember the other Architects out there have either been there or are probably going there. So, if your company doesn't allow you to share your knowledge, how about a pointer to your favorite site? Or, someone else's white paper, if it isn't yours, let me know and I will try to get distribution authority. The best words for me to hear is - Have you seen this? Or, have you been at this site? Or, have you tried this process. So, how about some help? BUT, please no advice about cheap wines!

If you have articles, white papers, sites of interest, let us publish them to this exclusive list of IT architectural interested people. Forward articles, white papers and interesting sites to mailto:ewita@ewita.com.

<top>

------------------------------------------------------

Feedback:
Request for information:

Announcement:

Dear Colleagues:

Please accept my apology for cross posting. Below you will find a URL that will take you to my survey instrument that is part of my dissertation project at Nova Southeastern University. I ask that you participate in the survey; information provided will be handled in a confidential manner and you have my assurance that you will not receive any third party mailing and or contact as a result of your participation.

If you decide to participate in the survey, please follow this URL link to complete the survey: http://rhodd.home.netcom.com/~rhodd/eiasurvey3.htm

Thanks for your cooperation.

Easton B. Rhodd

-------

Question: How are orgs showing the value of their architectural products?

What are the criteria that they are using to determine the value of each product? How are they proving to management and customers that the products are worth developing? submitted by Bob Cummings WSDOT

Response: Bob,

Knowing the IT reasons, and having a pretty good idea of the business reasons, as we held our first introductory meeting the minutes taker highlighted the positive comments and that was used to generate a "What's in it for me?" chart for future briefs. It's working pretty well. Submitted by Chris Turner cturner14@earthlink.net

-------

Question: Please excuse the prior message, the navigation did not work correctly. Outlook is linked to Word for some reasons and causing the problem

Response: Go into Outlook, got to Tools/Options/Mail Format. I just use Outlook with Rich Text formatting. It gets the job done. Submitted by Michael Dunham michaeldunham@earthlink.net

------

Feel free to add to any response, just email me the answer, I will include it in the next newsletter and forward directly to the person posing the question.

Readers: To respond, comment or ask questions send your comment to dmcafee@ewita.com

<top>

Area	Design Principles
General	The Enterprise will adhere to the application architecture policies and standards.
	The Enterprise’s enterprise architecture will define a consistent set of application development and testing tools.
	The Enterprise’s application architecture will be integrated and supported.
	Application development is a collaborative effort between centralized IT (CIT) and distributed IT (DIT). CIT is responsible for enterprise applications or when they are chosen as the provider of choice. DIT is responsible when the effort is specific to their business.
	The CIT is responsible for production integrity, reliability, performance, security, backup and recovery and, therefore, has approval or disapproval authority for deployment of production application software in the Enterprise.
	Applications must meet production standards prior to deployment in the production environment.
	The IT outsourcing contracts will be reviewed, prior to contract approval, by CIT for the purpose of architecture compliance.
Application Development	All application development tools must be Year 2000 compliant.
	Develop applications to meet customer defined criteria for ease of learning, use and support.
	Design applications to provide a consistent look and feel to users by utilizing Department and industry standards.
	Build reusable components to be shared across the enterprise whenever possible.
	Code applications for ease of development and maintenance.
	Utilize a web browser for the application interface when appropriate.
	Support communication between systems using middleware.
	Use asynchronous communications whenever possible to increase performance and scalability.
	Evaluate components based upon the "proven" criteria, where "proven" is defined as: Baseline use in EDD (i.e., has a track record) Enterprise scalability Fiscal solvency of vendor Future product growth potential Installed development base Length of time in the market Programmer productivity Support available Support through in existence contracts Taught in region Support of market leading and industry accepted standards.
	Design systems that facilitate the reuse of components across the enterprise.
	Establish a reuse methodology for the identification and implementation of components.
	Establish a component review board to identify common components.
	Establish component design reviews of all ongoing projects.
	Establish a repository for maintaining the information about available reusable components. The repository provides a place to store documentation about the component API’s.
	Assign ownership and maintenance responsibilities of components.
	Publish an application program interface (API) with every component.
	Harvest components from existing applications to build the component repository.
	Implement one business rule or function, or a small set of related business rules or functions, per component.
	Develop reusable testing suites for every component.
	A component testing suite contains special programs needed for calling a component, as well as sample input and output data for verifying results.
	Adopt effective component management methodologies, including the tools to support component reuse.
	Design component services to be callable by any application or any other component.
	Design new components to be platform independent.
	Purchase rather than build components whenever possible.
	Design components to be fully self contained.
	Minimize the number of languages used for application development.
	Support all approved languages with established training programs.
	Minimize the number of tools used for application development.
	Support all approved application development tools with established training programs.
	Minimize the number of application development support tools.
Middleware	Use middleware to facilitate reuse and shorten development cycles.
	Use middleware in heterogeneous, distributed computing environment.
	Middleware solutions must be scaleable to support increasing numbers of users without decreasing performance.
	Middleware solutions must support logging where applicable.
	Document application interfaces to facilitate reuse.
	Centrally manage enterprise-wide middleware as part of the strategic infrastructure.
	Ensure enterprise-wide middleware products are independent of code development tools where possible and practical.
	Use open standards and protocols rather than proprietary for inter-component communication.
	Must be scaleable to support increasing numbers of users with minimal performance decreases.
Componentization and Communication Models	Use open standards and protocols rather than proprietary for inter-component communication.
	Design enterprise applications to use asynchronous communication when an online application does not require an immediate response and/or updates can be processed out of sequence.
Session Workflow / Transaction Control	When distributed transactional integrity is needed, use transactional middleware for online transaction processing (OLTP) rather than the transaction management capability of a database management system (i.e. stored procedures).
	Enterprise transactional middleware must support ACID (atomicity, consistency, isolation, durability) transactional properties.
	Enterprise transactional middleware should support delegated commits for transactions.
	Use MOM products for applications that utilize an asynchronous communications model.
Data and Legacy System Access Products	Use best of breed gateways to provide access to a specific product / system rather than a "universal" gateway product that tries to provide access to multiple systems (e.g. IBM DB2 Gateway rather than a single DB2 / Oracle / Sybase / IDMS / CICS / VSAM / MVS access product).
	Use a single gateway product enterprise wide for access to an individual backend system.
	Use Database Gateways that use standard, open APIs such as ODBC and JDBC.
Internet/Intranet	Select mainstream tools based on business needs and business required volume.
	Design systems to ensure the maximum reliability and performance.
	Test systems to ensure the maximum reliability and performance.
	Choose standards that are open, pervasive and non-proprietary, whenever possible.
	Design systems to ensure secure access based on business needs.
	Design systems to ensure secure data transport based on business needs.
	Design applications to be portable across server platforms identified in the Enterprise Architecture (EA).
	Design applications considering the end user’s available bandwidth.
	Present information in a format appropriate to the user community.
	Design applications according to Marketing and Constituent Services (MACS) EDD Internet home page’s content, format, and presentation design guidelines.
Browser	Present information in a format appropriate to the user community.
	Use commercially available browsers rather than building a functionally equivalent product.
	Minimize the number of supported browsers (vendors and versions).
	Design Intranet applications to take advantage of features provided by the standard browser.
Server Software	Assign and configure Internet/Intranet servers based on function.
	Use a standard Application Programming Interfaces (APIs).
	Use software that supports the Infrastructure Domain/Systems Management Component of the EA
	Use standard security protocols as identified in the Security Domain.
	Support logging for diagnostic and user tracking purposes.
Search Engines	Minimize the number of searches required to locate information throughout the enterprise (Intranet Only).
	Searches of the Internet application will be provided by any of the commercially available search engines on the net.
	Publicize site to major search engines to assist commercial search engines in finding the site.
Authoring Tools	Training must be available for all tools selected (e.g., classes, books, videos, CDs).
	Scales to the needs of the users.
Groupware	Groupware requires a consistent infrastructure and communications backbone in order to support collaboration and communication.
	Facilitate real time access to information from any location.
	Implement single instances of groupware technologies whenever and wherever possible.
	Plan for adaptability to accommodate future changes in the environment.
	All products must be thoroughly tested prior to implementation at EDD.
	Groupware software will automatically update and organize the material whenever users connect their personal computers or workstations to the network.
Content Exchange	Must support document exchange with non-department users and applications.
	Utilize standard mainstream exchange protocols.
Electronic Mail (E-mail)	Administer E-mail servers as a part of the strategic infrastructure.
	Implement E-mail servers that support multiple standards based E-mail clients, (i.e., Exchange, Outlook, SMTP).
	Utilize a common E-mail directory service throughout the organization.
	Implement E-mail clients that have standard APIs for E-mail-enabling other applications.
	Implement security for E-mail message transport and storage.
	Minimize gateways with the aim of eliminating them entirely.
Calendaring and Scheduling (C&S)	Implement a C&S application that maintains transparent interoperability with other C&S applications and computing platforms (Open Standards).
	Implement a C&S application that provides a mechanism for attaching meeting materials or supporting documentation to the notification message.
	Implement a C&S application that allows the user to create both public and private notification groups and contact lists.
	Implement a C&S application that enables task and resource management.
	Implement a C&S application that can be accessed through a web front-end.
Electronic Document Management System (EDMS)	Utilize system with capability of storing and retrieving documents in native format.
	Allows the viewing or retrieval of a document in native format.
	Must be part of an existing security system, must not have it's own security services.
Workflow	Business processes must be validated and/or engineered before implementing workflow processes.
Desktop Publishing	Ensure desktop publishing is consistent with the enterprise print organization..

Best Practice	Rationale:
Select application development languages from the list of approved languages contained in the application development component.	Leverages internal and industry trained IT staff. Maximizes range of support tools available. Enhances maintainability. Increases likelihood language will be used and available in the future.
Utilize mainstream technology to ensure that systems are designed and built with products and technology that will be widely supported into the future. Consider application development tools based on IT research sources such as Gartner Group and META Group.	Based on a consistent set of criteria covering: Ability to execute Completeness of vision Research and analysis cover all segments of the IT industry Industry views are updated on an ongoing basis Leverages internal and industry trained staff Maximize range of available support tools.
Separate online transaction processing (OLTP) from decision support services (DSS) and online analytical processing (OLAP).	Information can be produced without impacting the performance of OLTP systems. Growth in OLTP is incremental and requirements are predictable. Growth in DSS and OLAP has been non-linear and requirements are difficult to predict. OLTP allows the customer to do their business, it is operational; decision support allows the customer to manage their business, it is strategic and tactical.
Use a data warehouse(s) to accelerate decision making and reduce the development burden	Much of the development that occurs in OLTP systems supports decision support and analytical processes. Moving these functions to a data warehouse environment stabilizes the OLTP systems and provides greater accessibility and scalability to meet decision support needs. Ad hoc data requests can be fulfilled quickly. Decision makers need access to information and the tools and skills to utilize that information to the greatest advantage. Supports more mature and advanced data analysis and reporting tools.
Customized development should only occur when critical business needs cannot be met by commercial applications.	Business functions (e.g., attendance and travel) common to all businesses can be provided by software vendors at a lower cost than customized development. Staff use standard systems and processes for administrative functions; therefore, training and skills are leveraged. Reduce TCO for the enterprise. Follow a Total Cost of Ownership (TCO)
Methodology to achieve the lowest aggregate cost to the Enterprise.	Leverages core competencies, skill sets, and tools. Leverages and utilizes proven products. Lowers total enterprise costs. Decreases range of products. Evaluates a product or technology over its entire life cycle.
Provide adequate training programs to ensure application developers are highly skilled in identified application development languages and tools.	Enables the enterprise to leverage trained development staff.
Emphasize the use of standards and best practices to reduce integration complexity.	Enables the enterprise to focus staff resources. Reduces required skill sets. Facilitates a consistent look and feel across applications. Leverages staff training and skills.
Application delivery should be evolving towards an object-oriented approach.	Facilitates reuse. Facilitates ease of maintenance. Facilitates N-tier development and the migration to N-tier development. Reduces application complexity.
Document applications in a repository.	Facilitates reuse. Facilitates ease of maintenance.
Strategic N-tier Best Practices Plan for scalability and increased functionality in applications and systems.	The Enterprise will continue to experience rapid change in business processes; therefore, the applications supporting these processes must be able to adapt and respond quickly. Most systems and applications evolve to support new business requirements.
Develop applications that are "highly cohesive" and "loosely coupled." A highly cohesive application is one that implements one business function (e.g., print check) and is invoked for one purpose. Loosely coupled applications can accomplish a task without requiring or waiting for a response from another application.	High cohesiveness enables reuse and sharing of common application business rules. Loose coupling allows applications to operate independently.
Design applications to leverage continuing changes and improvements in technology.	Enhances ease of maintenance. Reduces time to change/repair code.
Build applications and systems to use modular, shareable and reusable components.	Facilitates ease of development and maintenance. Duplicate functionality in multiple systems can create redundant and inconsistent results. This requires additional reconciliation processes, which add complexity and inflexibility to the architecture. The architecture will clearly define where functionality will reside and how systems will share data and business logic. Leverages department resources so as not to "reinvent the wheel." Application code can be written once and reused whenever feasible. Applications can be built by assembling and integrating existing components, rather than by always creating custom code. Shrinking cycle times do not allow for artisan programming.
Implement business rules as discrete executable components or services.	Isolates the business rule from changes in the user interface and data access logic.
Layer strategic application systems using an N-tier client/server model.	The Enterprise will continue to experience rapid change in business processes; therefore, the applications supporting these processes must be able to adapt and respond quickly. N-tier client/server architecture is the most flexible and scaleable of the existing architectures. Allows applications and data to be designed for enterprise use and not just for a single business process. N-tier applications are easily modified to support changes in business rules. N-tier applications are highly scaleable. Any combination of user interfaces (e.g., character, graphical, web browser, and telephone interfaces) may be implemented in an N-tier application.
Business units are responsible for defining and maintaining the integrity of business rules.	The business units are best positioned to be responsible for the definition and integrity of business rules, and for communicating changes in business rules to IT. Every business rule should have an assigned custodian in the business unit.
Document the implementation of all business rules.	Establishes a common language and facilitates communication between business units and IT. Documentation practices support both business and IT organizations. Ensures that all business rules are implemented. Allows discussion between users to ensure completeness of business rules.
Architect systems to be business event driven rather than process or data driven.	Business events represent the essential activities of the business and are easy for business users to understand, identify, and verify. The closer the system is to business operations the easier it is to identify where changes must occur when the business event changes. The business events that a system captures and responds to clearly define the boundaries of a system.
Install server resident business rules to improve performance, reduce software distribution complexity and increase reuse.	Server based business rule applications enable reuse and sharing of the business application logic across the enterprise. Business rules update shared data; the update logic used must be consistent from application to application.
Partition applications so business rules control access to data.	Data is created and used by business processes. In computer applications, data must be created, used by, and managed by the application component that automates the business process. Accessing data in any way other than by business process bypasses the rules of the module that controls the data.
Write departmental, mission critical business rules in a non-proprietary language.	Maximize software reuse. Maximizes application portability. Leverages internal and industry trained programming staff.