• The World depends on a Binary System with

  • IT Architectural views from top to bottom

  • Binding of hybrid OS Platforms

  • Artistic Designs and Branding

  • Concentric Content Management Systems (CMS)

  • Network Architecture

  • Limits are those you bring with you

  • Focus Social Media

  • Global Communication eCommerce Systems

  • More

    Business Information Technology


    Business Intelligence

  • More

    Network Architecture


    Network Architecture

  • More

    Corporate Applications Implemented

    IT Architecture

    IT Architecture Clients


asaaInformation Technology (IT) Architecture is a blueprint that is developed, implemented, maintained, and used to explain and guide how your organization’s IT and information management elements work together to efficiently accomplish the mission of the organization. An IT Architecture addresses the following views: business activities and processes, data sets and information flows, applications and software, and technology. A proper Architecture is not limited to hardware and software issues. Along with the expertise of A Science and Art, IT Architecture is a plan that addresses how your organization will migrate to the new targets over time.

There are several steps A Science and Art takes in achieving a blueprint for IT Architecture:

         Who and what are your IT Architectural efforts going to cover?
         What general IT principles will guide your efforts?
         How does your office do its business, what Information Technology is used,
         and how is it used?
         What do you want your IT Architecture to look like in the future?
         What are the differences between your baseline and the architecture you
         want to achieve?
         How will you bridge the gaps between the baseline and the Target Architecture?
         Start implementing the plan to bridge the IT architectural gaps.
         A Science and Art IT Architecture is a process, not a document.

A Science and Art detailed steps of IT Architectural Plan

  1. Before you do anything else, you need a vision of what you are trying to accomplish and some specific objectives. The vision is a statement of where the organization’s IT environment and capabilities should be in the next three to five years. A key element is the issue of scope. Are you setting out to do an IT Architecture for an organization, a business operation within one organization, or a business operation that involves multiple organizations? There are trade-offs in the scope chosen for an IT Architecture; a smaller scope allows the Architecture to be tailored to very specific program needs and is easier to develop, while a broader scope realizes greater benefits in interoperability, procurement and support cost savings, and efficient information flows. You need to take resources into account when defining your objectives.

    A question that may need to be asked is whether you should seek to do a complete IT Architecture or focus on a specific aspect of an Architecture. Usually it is a good idea to do a complete IT Architecture, but in some cases an aspect of the organization or business process needs action immediately. You may need to concentrate on a single process rather than completing each step for the entire organization. The objective, after all, is to improve the products and services provided to the public, not produce an IT Architecture for Architecture’s sake. A complete Architecture should almost always improve the business process, but if slicing the job differently produces quicker benefits, then that should be considered.

    Another first step should be a set of IT Architectural Principles – statements of preferred direction or practice on how the organization or process will use IT. These can help to provide a context for specific architectural decisions made later in the process and also help to make those decisions consistent. Some may seem so obvious that you first question why you should bother, but by documenting Principles and keeping them as a visible part of the process they are less likely to be overlooked.

    There can be a wide variety of IT Principles dealing with the basic IT Architecture itself, the use of a common user interface, the use of modular components for systems, and so on. You should review some examples done by other offices to help you focus on what should be done.

    When defining your vision, objectives, and principles, you need to make sure that they are consistent with the goals of your Strategic Plan and Strategic IT Plan, as well as with the Departmental goal of achieving an electronic environment.

  2. The next step in the IT Architecture process is to characterize your current status. This means that at a given time you take a snapshot of your existing IT capabilities. The word “characterize” is used because it isn’t usually necessary to identify and analyze everything IT or information- related in the organization. You just need enough data to understand the basic situation you are in and the problems that exist, and to develop an idea of where you want to go. The scale of this task depends, of course, on the size and complexity of the organization. It can vary from a relatively simple job to a complex and time-consuming one.

    It is essential to remember that an IT Architecture isn’t just deciding on a computing platform, an operating system, etc. Your organization exists to provide some product or service, and IT is a tool to do that. So the question is whether IT is being used in the most effective way to accomplish the organization’s program goals. To determine that, you need to know a lot more than just what equipment and software you are now using. If you don’t know enough to evaluate whether the work processes should be re-engineered or not, then you don’t know enough to do a complete IT Architecture. The types of information you need can be placed into a number of categories. The following are just examples – different organizations choose different ways of characterizing their baseline, but these give an idea on one approach.

    What Work is Performed? You must have a clear understanding of what work the organization performs and where it is performed (anywhere from one small location to throughout the nation or even the world).

    What Information is Needed for that Work and by Whom? You need to understand the basic flow of information, not just within your organization but also to and from outside customers or suppliers, and what the information consists of, how that information is organized, and whatever else is needed to give you a clear understanding of the information.

    What Applications are Used to Process that Information? What software is used to process, analyze, move, etc., the needed information? What types of file structures are used? What protocols are involved in transfers?

    What Technology is Used to Perform the Work? What IT hardware is currently used, including telecommunications and networking equipment?

    Many have found that besides inventorying these things it can be very helpful to interview key IT staff, end-users, and managers; these are the people who usually know the most about what actually takes place, where problems may exist, and where opportunities for improvements may exist. You need to compile all the information that you find and then organize the data into your baseline document.

    While you may collect the information in categories like those above, by the end of the process you need to know how they all inter-relate. What depends upon what? Once you have a good understanding of your current situation you are ready to move to the next step.

  3. At this point in the process you should know where you currently stand. Now you need to try to figure out where you would like to be (or need to be) in the future. How should the workflow ideally work? What generic types of applications and technology would be used? You are developing a model of the IT structure, not identifying the specific standards for products to be used (later you will create standards and guidelines that will be used by the organization for the acquisition of technology, applications, and services, but those are not the Target Architecture itself). To do this step effectively you must first understand the forces that are driving the need for change – the “drivers” in the business and technology areas.

    Business drivers are ones telling you that you need to do business differently. Customers may be demanding better or different services. Organizations that you work with may want to change how you exchange data. The methods now used to do business may not be cost efficient in the future. Or the drivers may be instructions from higher-level organizations or from laws. As part of the Federal government, all agencies need to consider the impact of the Paperwork Elimination Act on their future IT Architecture. This law says that by October 31, 2003 the public must be given the option to transact business with the government by electronic means, and that means that agencies will need to have digital signature procedures in place. This is part of the larger push towards electronic commerce. Within A Science and Art, the goals in your Strategic Plan and of an electronic government are drivers that must be taken into account.

    Technology drivers are ones that tell you that technology is giving or will give you options for doing things differently (and hopefully better). Many parts of A Science and Art, for instance, realized the potential of the Internet and started using it to provide products and services to the public long before any outside forces told them that they should do this. What other technologies are out there that may provide you with similar future opportunities?

    IT security is a particularly strong driver that should be addressed when developing all parts of the Architecture.

    By analyzing these drivers and your current baseline, you can start to define your future business and technology models – how you see the future business process working, the general technological tools needed to make that process effective, and how those tools need to interrelate. You may then break down these models into more specific models dealing with specific areas (e.g., they could be data models, system models, infrastructure models), depending upon the complexity of the organization or process involved. In the final analysis you get down to identifying specific approaches the organization should take in the future.

    The Target Architecture is the heart of the process. The four components (business activities including performance measures, data sets and information flows, applications and software, and technology) of the IT Architecture need to be modeled separately. Security and privacy considerations should be addressed throughout. The process consists of defining each set of architectural components and its key attributes. The desired capabilities of and relationships between components are then defined. The result is an organized set of definitions and models from which drawings can be made to reflect the different views of the architecture. Again, the relative complexity of the situation will determine how detailed and extensive this effort and documentation needs to be. The four components are then synthesized into a comprehensive Target Architecture.

    The Target Architecture should be looking five years ahead. Because it is a model that does not designate specific products, it can look this far into the future. New technology could lead to changes to specific standards for an Architecture every two or three years, but these changes would not normally affect the model of how the technology elements support the business.

    It is a good idea to develop an “evolvable” IT Architecture. Technology changes almost daily – you need a structure that can accommodate these changes as easily as possible. Some rules for evolvable systems architectures also apply to broader enterprise architectures: keep things modular, have well-defined boundaries between systems and components (crisp interfaces), use industry-standard interfaces, use open-systems standards, and use common mechanisms whenever possible. Planning for modular systems with clear boundaries allows you to change portions of the IT Architecture without having to revise everything in the Architecture, and also helps you see how changes in one part of the Architecture may affect other elements.

    Depending upon the size and complexity of the organization, all of this can produce a confusing quantity of data. There is no standard way to organize and display this data. You can look at examples of what others have done and choose the methods most useful for your particular situation and needs.

  4. So by this time you should know where you are now and where you want to be at some point in the future. It is time to evaluate how long that road is. How far is the organization from the target?

    The gaps have to be identified for each component of the IT Architecture. Where are the gaps large and where are they small? How difficult will it be to bridge those gaps? How much time, money, resistance from users, etc., may be involved? The nature of your organization plays a great role in this analysis. A smaller centralized organization or one where IT is controlled by one office will face different issues than a decentralized office with little or no central IT control.

    There may be gaps that are theoretically easy to solve - say a change with no complicated shift in technology and that will actually save money immediately – but that would face such fierce resistance by users that the organization would decide that there is a large and difficult gap here, with difficult decisions as to whether and how to bridge that gap.

    Knowledge of all this is necessary to go to the next step – developing the game plan for migrating to the Target Architecture.

  5. You now know your baseline, your Target Architecture, the gaps between the two, and the issues involved in bridging those gaps. The next step is to plan for when and how you are going to actually do that bridging.

    Many factors are involved, including those that you looked at in the gap analysis. Are there “quick wins” where the organization can realize benefits right away and for a minimal cost and effort? Besides the immediate benefits, these can show doubters the value of an IT Architecture. Or are the real problems ones that need immediate concentration on more major and long-term tasks? Which actions depend upon other actions to be effective? In some cases at least an informal cost-benefit analysis may be needed.

    There are no standard answers here, other than that you need to do the analysis and make a plan setting priorities for implementation. A timetable should also be created, recognizing that budget considerations can have a major impact on that schedule. In some cases the hardest question may be who will do the work – who will be responsible for doing what, and how? A plan without assigned responsibilities rarely produces anything. So if a contractor develops an IT architectural document for you, and it is placed on a shelf, you probably wasted your money. The planned migration approach developed should be reflected in your Operational IT Plans.

    A key tool for migration is something called a “Technical Reference Model,” or TRM. A TRM generically identifies the various software, hardware, and interface services needed for the organization or business operation. The TRM helps you see how everything fits together, guides the acquisition of IT products and services, and helps provide a base for future architectural changes. It also serves as the basis for developing a Standards Profile, which identifies acceptable options within the IT Architecture for filling the needs of the TRM’s services. These options are specific types of equipment, software products, protocols, etc. There may be a single standard for some elements and a range of acceptable options for others. It is important to be aware of situations where higher-level organizations or outside business needs may constrain your choices, such as where a higher organization level has already defined a standard for something throughout the organization. A Standards Profile should guide acquisition and development activities.

    Another key part of the plan is identifying the processes to be used for implementation. A “governance” process needs to answer the following questions: How will we ensure that people planning and developing IT systems do so in a way consistent with the Target IT Architecture? How will we ensure that IT procurements are consistent with the Target IT Architecture (all procurements, not just major system procurements)? How will we determine if exceptions or changes to the IT Architecture are needed for a specific system or procurement? How will we track the implementation of the IT Architecture Migration Plan and the benefits/flaws of the IT Architecture? How will we keep the IT Architecture up-to-date, reflecting changes to the business, development in technology, etc.?

    Operating unit CIOs are expected to include a governance plan as supporting documentation to their Architecture submissions to the Department CIO.

  6. Obviously the steps leading up to this one will be of limited value if implementation never takes place. But what does “implementation” really mean? It does not necessarily mean that the organization must immediately convert its IT and information systems to the Target Architecture. If the IT Architecture is guiding the procurement and development of technology and systems, then it is being implemented, even if it may take a number of years before the Target Architecture’s goals are fully realized. As mentioned above in Step 5, a migration plan can identify priorities where the application of the organization’s available resources and time can produce the greatest benefits.

    For implementation to take place the Architecture must be understood by all key players in the organization. To be fully effective the Architecture cannot be a tool just used by some or all of the IT technical personnel. Top agency management and program personnel need to be aware and supportive of the Architecture. There needs to be integration with the program planning and the budget processes. For instance, the agency should not propose projects for funding in the budget if they are inconsistent with the Architecture and the Migration Plan. The technical opportunities that may be identified in the Architectural efforts can point out ways to change the business process, to use technology to do things in a radically different way (rather than just upgrading equipment that once automated old methods of doing business without affecting the way the essential business was conducted). Conversely, other types of changes in business needs chould lead to changes in the Architecture. Business (program) and Architecture feedback is crucial to full and effective implementation.

  7. Technology is changing very quickly these days, and that trend doesn’t appear likely to slow down or stop. Business needs and processes also change over time. So a Target Architecture, whether fully implemented or not, that addresses how IT and information will serve business needs must be periodically reviewed and updated to reflect those changes.

    The review can affect any of the other six steps identified – important technology or business changes may require a new vision and new basic objectives. New technology may provide opportunities for a revised Target Architecture, and you may need to re-evaluate your baseline to allow you to identify the gaps that need to be spanned to reach that new target. If architectural documents remained unchanged the chances are increasingly high over time that the organization isn’t maximizing the possible value of new technology and is restricting creativity.

    Ideally at least annual updates should reflect changes in strategic plans and budget status. Since a good IT Architecture deals with interfaces with other organizations, you also need to stay aware of technological changes in those organizations and make sure that they are aware of changes that you may be planning to make.

    Another type of review that needs to be conducted is an assessment of the maturity level of an organization’s architecture program. A Science and Art has established a self-assessment guide for this purpose and requires periodic reports on the results. These results should guide your efforts to improve your program.

f t g