Showing posts with label application systems. Show all posts
Showing posts with label application systems. Show all posts

January 16, 2008

Enterprise Architecture Terms and Taxonomy

A key foundation to developing enterprise architecture is getting the EA terms and taxonomy right for the organization, so that there is a common language and understanding by business and technical subject matter experts of what all things EA means.

Here are some fundamental terms and a high-level taxonomy for them (prior to having these, I found considerable confusion in the enterprise as to what many of these terms meant and they were used incorrectly and interchangeably by various users):

1) C4&IT—Any equipment or interconnected system or subsystem of equipment, or techniques used in the automatic acquisition, storage, manipulation, management, transmission, or reception of digital, voice, or video data or information to the appropriate levels of command. This includes command and control, networks, common operational picture systems, information assurance services, communication products and standards, computers, ancillary equipment, software, firmware, procedures, services (including support services) and related resources. (short definition─Command, Control, Communications, Computers, and Information Technology)

2) FISMA Systems—An application or general support system that meets the requirements of the Federal Information Systems Management Act (FISMA) of 2002, including completion of certification and accreditation, risk assessments, policies, and procedures, security plans, security awareness training, annual security testing, remediation procedures, incident response procedures, and contingency plans. (short definition—systems as defined by FISMA).

a. Application Systems—A discrete set of information resources [i.e. applications] organized for the collection, processing, maintenance, use, sharing, dissemination, or disposition of information. (short definition—one or more applications).

i. Applications—the use of information resources (information and information technology) [i.e. hardware, software, and database] to satisfy a specific set of user requirements. (short definition—combination of hardware, software, and database).

b. General Support Systems—An interconnected set of information resources under the same direct management control that share common functionality. It normally includes hardware, software, information, data, applications, communications, and people [i.e. infrastructure]. (short definition—IT infrastructure).

3) Products and Standards

a. Products—Includes hardware, the physical parts of a computer system, and software, the programs or other “instructions” that a computers needs to perform specific tasks.

b. Standards-- Guidelines that reflect agreement on products, practices, or operations by nationally or internationally recognized industrial, professional, trade associations, or government bodies.

The way to read the taxonomy is that C4&IT at the top is the CIO world of work and it is composed of Command, Control, Communication, Computers, and IT. C4&IT decomposes to FISMA Systems (since all systems must be FISMA compliant). FISMA Systems decompose to Application Systems (and their applications) and General Support Systems (infrastructure). And these systems (applications systems and general support systems) decompose into hardware and software products and standards.

The short working definitions are fairly straight forward and the longer definitions are based on public information definitions from National Institute of Science and Technology (NIST), Office of Management and Budget (OMB), The Department of Homeland Security (DHS), and The Department of Defense (DOD).

These terms and taxonomy should help enterprise architects and their users differentiate C4&IT, Systems, Application Systems, General Support Systems, Products, and Standards, and maybe even widgets by inference. :-)


January 3, 2008

Customization and Enterprise Architecture

While User-centric EA seeks to provide useful and useable products and services to the end-user, the heavy customization of major application systems to meet user needs is a huge mistake. Major customization of IT systems is a killer: it is a killer of the application and a killer of the underlying business processes.

What do I mean? When you heavily customize an application system (and I am not talking about changing settings), you do the following:
  • You greatly increase the implementation cost of the system, since you have now added all sorts of modifications to the system.
  • You greatly increase you maintenance burden, because new versions of the software often will need to be recoded.
  • You hamper the ability of the system to interoperate with other systems that it was designed to work with (even when it is built with open standards), since you have tinkered and tweaked away at it.
  • You missed one of the biggest opportunities to improve and reengineer your business processes; instead of aligning your business processes with those identified (by usually hundreds, if not thousands of other organizations) as best practices and written into the software, you have made your enterprise the odd man out and overwrote the best practices in the application system with your specific way of doing things. That’s a big no-no.

Let’s face it, most (and there are exceptions to every rule) organizations at their fundamental “business” (not mission) practices are often close to identical. Areas like finance, human capital, and even IT and considered utilities to the organization. These areas are often run in ways to exploit enterprise solutions for large organizations (for example, one timekeeping system, one payroll system, or one general ledger system ) and these functions are the first to be looked at for integration and downsizing on the corporate side during mergers and acquisitions.

Instead of insisting that your processes are so different, see why others are doing it another way and whether there is merit in it, before you go and customize and chip-away at the system—you may be doing yourself more harm than good. Generally (and there are exceptions to every rule), you’re better off changing business processes to meet widely used and verified software.