Post No. 1- The Technology Stack and future topics
I will continue to share with you my thoughts and learnings
on the domain of enterprise architecture. What have been published so far has
always discussed enterprise architecture from the viewpoint of the business;
which is great, as business the true driver of EA initiatives .In the coming
few months my blogs will cover topics in enterprise architecture from view
angle of technology leaders.
The Open Group’s Allen Brown once said “The goal of
enterprise architecture is boundary-less information flow, where all systems,
IT and non IT, interoperate”. Whether you agree or not with how he expressed
the goal of EA, the saying puts it simply: EA involves IT and non IT domains
and that’s business.
Aside from the business part of EA, which I have covered heavily
in my previous posts, there are several layers that collectively describe what
we call the Enterprise Information Technology Stack. These layers are:
- · Applications
- · Data or Information
- · Infrastructure
- · And the cross cutting thread: Security
Gartner defines the Enterprise Technology architecture (ETA)
viewpoint as “the reusable standards, guidelines, individual parts and
configurations that are technology-related”. Across all the stack layers
standards and guidelines should be supporting not only interoperability but principles,
objectives and requirements set by the business layer of EA.
The terminology stack itself is very technology specific.
Often used by and to CIOs and CTOs and technology experts to describe a visual representation
of the interaction between layers. The understanding of how the stack is
composed in terms of interactions and boundaries allows them to develop
capabilities as well as managing change by governing the impact of the new
capabilities.
I will continue to share with you my thoughts and learnings
on the domain of enterprise architecture. In the coming few months my blogs
will cover topics in enterprise architecture from view angle of technology
leaders. It is however important to note that my intention won’t be on bringing
down topics of mere technical nature. But rather, the guidelines, principles,
standards and components that represent the technology related domains, such as
applications, data, infrastructure, in the overall enterprise architecture. Security
related posts, which is a critical crosscutting thread in EA, will find its way
to this blog.
Post No. 2- The application stack or the software services
network
As part of my readings this week about technology stack
layers, I came across a Forbes tech page article by Larry Hawes, titled “Enterprise
software Architecture: a Network of Services, Not a Layered Stack”. It has been
the source of this post.
If we would like to focus on the application layer of the
enterprise technology stack; how would we like to visualize it: as a stack or
as a network of services?
The term application stack gives the indication of hierarchical
interaction, where every layer can only interact with the layers above and
beneath it. This representation does not go well with the guidelines and principles
that are set by any decent EA program that calls for scalability, performance
and flexibility.
Software vendors are no longer adopting these traditional
stacked architecture. Their architectures can be described as a network of
functionalities and services. Multiple services can be combined to form an
application for a specific purpose. With this designs application developers can
build solutions that allows enterprise to reach and connect with their larger
ecosystem, by pulling data from on service node to be used by several internal
and external service nodes.
The dynamic nature of this network architecture will be of a
profound value to the business. It will allow business to be able to face
changes, adopt technology advances and even try and embrace new business models
without worrying to limited by the limitations of the traditional hierarchical
application architecture.
Post No. 3- Skills required by every stack layer
Someone is ought to carry the architectural work. But what is this talent that should have a
good level of expertise in every layer of the stack, along with in-depth
understanding of the business!!!
Fortunately, FEAPO (Federation of Enterprise Architectural Professional Organizations) developed a framework that can be used
for identifying competencies and critical skilled required in an EA team.
No surprise, the framework is based on the BAIT+S (Business,
application and information, technology and security). Competencies are
identified for each of the following roles:
- · Business Architect : to answer why the change is needed
- · Information architect : to answer how information moves
- · Application Services Architect: to answer how systems deliver services
- · Tech Architect : how technology support them all
- · Security Architect : for the management of secure data
An article by Gartner presented two different thoughts: An
Enterprise architect as a higher level role and not a maturing role, and that business’s,
information, technology and solution architect roles have a specific expertise
that is measurable.
To summaries, thanks to FEAPO and Gartner, we do now have
guidelines that organizations can adhere to when establishing and progressing
an EA career path. Internal staff can be prepared to take such roles, or if organizations
wishes, selection criteria can be tailored to hire from outside.
Fellow Penn Staters interested in this post can contact me
to give them a copy of a paper which my group have prepared on EA careers as
part of a course requirement.
