Post No.1-
Setting up an enterprise technology architecture
According to Gartner: “The enterprise technology
architecture (ETA) viewpoint defines reusable standards, guidelines,
individual parts and configurations that are technology-related (technical domains).
ETA defines how these should be reused to provide infrastructure services via
technical domains.”
While this might seem as pure technical choices, it is
critical to note out it is just one layer of a stack, therefore, any design
option should be supported and justified by requirements driven from the other
layers: business, data, applications and security.
The primary objectives of developing an enterprise
technology architecture are:
- To effectively remove hardware obsolescence or vendor dependency as a requirement
- To periodically review the systems in support of the organization’ needs
- To ensure that the rapidly changing external and environmental trends are enforced to significantly change the business and technical environments within organizations
Developing the architectural products of an Enterprise’s ETA
is not an easy task. It is a process that usually starts by finding out where
the business is headed and how that will affect your technical architecture. Business strategy
is the primary
driver for the
development and implementation of
the technical architecture. The structure of the
organization, the business model and the geographical locations of the offices
are some of the very basic inputs that dictate the model of your ETA.
The extracted requirements are used as an input to develop
the architectural products,
which are a set of models and
views of the
organization. Requirements such
as business scalability, Latest technology and environmental trends and
competitive advantage are all considered and developed into an architectural
context.
Once the architecture is clear, Technical architecture
requirements are then derived from the architectural requirements. These
technical requirements will guide the engineering of
the organization’s information
systems and technology
infrastructure. Technical domains
are then to be defined into Domain-level technical architectures along with the
domain-level principles that govern the selection and use of the technologies
in each domain including product and configuration standards.
The ETA can be part of a complete EA initiative or not. In
both cases its implementation involves a gap analysis exercise, based on which
a migration plan is developed and implementation projects are defined.
The process described in this post is taken from “A
FRAMEWORK FOR DEVELOPING AND IMPLEMENTING THE ENTERPRISE TECHNICAL ARCHITECTURE”
a paper by Tiko Iyamu, Tshwane University of Technology
Post No.2-
Measuring the value of the ETA
Once you have an ETA in place, it is wise to define/develop
a set of metrics to measure the value of enterprise technical architecture.
This will help the ETA program to gain the trust of the executive team and secure
the future investments. In addition to this, it will act as a source of input in
the technology planning process.
To satisfy Business stakeholders, IT leaders should define Enterprise
Technical Architecture Metrics that is mapped to Business Metrics, an example
would how a new technology has increased the productivity of the customer services
department. This metrics relates well the business people and allow them to see
the technology as a business enabler function.
Some of the metrics should be pertaining to technology
standards, and how much it was followed in different projects. These metrics
will help us measure the compliance in order to ensure that we reap the
benefits of lower total costs of ownership and costs to change. Examples of
these standards are: The number of designs that are 100% compliant, the number
of projects actually checked for compliance (vs. all projects), Time taken to
design and the Year-over-year improvement across many projects.
Other metrics can measure the degree and value of reuse. The
number of technical patterns reused, the number of components reused and the
number of technical serviced reused, are all examples of metrics that shed the
light on the value of the ETA.
In general, metrics that demonstrate costs savings should be
tracked and reflected to the business. Without such metrics, business will
continue to see technology as a cost center and fails to see beyond this.
For more in this topic please read the Gartner article “Develop
Enterprise Technical Architecture Metrics to Demonstrate Enterprise
Architecture Value” at https://www.gartner.com/document/1330249
Post No.3- Auditing
the ETA
ETA is often perceived as a mature field, yet many
organizations fail to commit to many aspects of it, in particularly the
documentation.
Last semester, I was asked by a colleague to review the ETA
of his organization. I listed down some questions that resembles my
understanding of what to expect in an ETA.
First and Foremost, I found out that the mission, vision, goals
and objectives of the enterprise are not part of the architectural sets.
Although some of the architectural decisions were backed with business
requirements, not all of the technical requirements could be traced back to
business drivers in the documents. I had to ask them for it to get the answer,
verbally.
In other areas, they had great documentation. Conceptual, logical
and physical models were there. Inter-operability requirements were well demonstrated
along with functional and non-functional requirements. In addition to these,
various products standards and configuration standards were stated in the
documents.
They however lacked in to major areas:
- They did not have metrics of any sort
- No clear governance on how this ETA is maintained. They should have considered defining how a new technology is introduced and the decision process behind it
Overall, I felt their ETA was so complex and not well acquainted
to the business and its future plans.
