IT Architects™ Technical Architecture
The purpose of a Technical Architecture assessment is to categorize and inventory systems and their supporting technologies, document existing technical attributes, and compare current to target technical architectures. The IT Architects™ Technical Architecture framework helps the organization assess its technology and infrastructure requirements by completing the following tasks:
- Categorize and inventory physical systems and components that comprise those system
- Determine technical attributes including hardware platform, language, network, integration adapters, protocols, DBMS and other technology components – for each system
- Assess high-level quality of each system
- Summarize current technical architecture findings
- Compare current technical architecture to target technical architecture requirements
IT Architects has devised a robust analytical tool to assess the technology lifecycle of an organization’s technology and infrastructure. A Technology Lifecycle Assessment is conducted to define the current support state of tools, software, hardware and other technologies supported by an organization for current and future implementations. It is important to note an assessment of the technical architecture must consider current or immediate requirements, as well as the future demands to meet mid-term (1 to 2 years) and long term (+2 years) technology and infrastructure requirements. Long-term requirements are driven by product and market opportunities, among others, that have not yet matured but will become a critical component of an organization’s technology and infrastructure architecture to be able to compete in a highly competitive industry.
This will also provide the right impetus for the planning of the research tasks for technologies; and for planning the migration tasks for technologies that need to be phased out or abandoned as they become obsolete and provide insignificant value.
Principles of a Good Technical Architecture
An architecture is the result of technical, business, and social influences. Technical influences drive the creation and realization of the architecture. Business influences drive the requirements and definition of the problem set. Social influences determine the architecture from the basis of the environment and the people involved (end users, development team, sponsors, etc.). In addition to responding to these influences, a “good” architecture must meet certain goals and principles that are generally not reflected in these influences.
There are a number of factors to consider while designing an architecture. Our underlying goals for a good architecture include the following:
Scalable: Scalability implies the ability for the architecture to grow and accommodate increasing numbers of users, applications, and systems. The architecture must also accommodate changing business processes, migrating data, and new uses of existing data.
Flexible: Flexibility implies the ability for the architecture to remain vendor and technology independent. Technology will always influences the structure of the architecture but in no means should constrain the architecture.
Extensible: The architecture should be able to extend from its first implementation. It should grow and accommodate new business requirements as they are determined and incorporated into the architecture.
Reusable: The architecture should foster reuse where possible. Equally important is the underlying effect that implementation of the architecture encourages the development of reusable components.
Open: The architecture should incorporate open standards wherever possible. Open standards contribute to implementing many of the other principles of a good architecture.
Secure: Today’s environment demands that an architecture appreciates and handles all manners of security on data and business processes.
Semantics: Common semantics is a key goal of an architecture since it enhances the ability of an architecture to maintain many of the other goals. Common semantics allows an architecture to provide abstraction (at the business level) and communicate with different systems and business processes in a maintainable manner (at the technical level).
Additionally, a good architecture is designed with the following guiding principles:
At the application level, the architecture is comprised of well-defined services with functional interfaces that enforce the principles of information hiding, encapsulation, and separation of concerns.
Separation of concerns is a focus of the architecture because it allows development teams to work independently of each other.
Tools and approaches should be chosen for suitability to purpose, and incorporate best of breed technologies wherever appropriate.
Encapsulation and information hiding allow the services to insulate applications from platform dependencies.
The architecture should not depend on a particular version of a product or tool.
Design services that promote the separation of data, business logic, and presentation so that tight coupling among the three is avoidable.
Patterns should be applied where appropriate. Patterns offer successful approaches to solving common architectural issues with a structured, well-defined solution. IT Architects is a big proponent of this point.
A good architecture incorporates these principles and goals as best as possible. There are always circumstances and issues that try to circumvent an organization from applying sound architectural principles. Many external factors influence the adoption and implementation of a good architecture and it is up to an organization to undergo the cultural and technical migrations in order to support the architecture in an ongoing fashion. An architecture founded on these principles will grow and mature with an organization as it grows and matures.