EA is supposed to cover all areas of the LOB and help the enterprise to achieve its overall business objectives through IT.
Enterprise Architecture has three layers, abstract, logical
and physical, the success criteria of the EA initiatives, relies heavily on how
the business vision and goals are aligned and mapped to the architecture and
design components across domains and eventually to the implementation. Ideally,
how many architecture domains an enterprise architecture should encompass to
address all business needs?
1 EA is beyond an Abstract Concept
EA is supposed to cover all areas of the LOB and help the enterprise to
achieve their overall business objectives through IT, so, at the high level,
the model is Business Model -> Business Capability -> Solution Domain,
and then at the lower level, within the highlighted domains, the model can be
Business -> Information -> Application -> Technology.
· It
appears EA is more of an abstract concept:
(1) It is measurable
(2) It has deliverables and those are universally accepted
(3) Those deliverables can be used in the next phase of
architecture work, and
(4) EA is supposed to cover all areas of the LOB, and help
enterprise to achieve their overall business objectives through IT, and
(5) The EA framework you take also depends on the nature of
business and the type of project
·
EA
Domains may include:
1) Business Architecture
2) Application Architecture
3) Security Architecture
4) Infrastructure Architecture
5) Information Architecture
6) Network Architecture
7) Integration Architecture: Subdomains may be Message, Data, Service based depending on the maturity model.
8) Data Architecture: Subdomains may include structure data, semi-structured and unstructured contents as well.
2) Application Architecture
3) Security Architecture
4) Infrastructure Architecture
5) Information Architecture
6) Network Architecture
7) Integration Architecture: Subdomains may be Message, Data, Service based depending on the maturity model.
8) Data Architecture: Subdomains may include structure data, semi-structured and unstructured contents as well.
·
Structural
architecture vs. functional architecture: EA could benefit hugely from a language that clearly differentiates the structural systems of an organization
from the functions of the organization that are the result of those systems
interacting. Ideally, we need a
structural architecture (anatomical) and an accompanying functional (metabolic)
architecture. For example, are services a part of the organization’s
"anatomy" or a "metabolic process" produced when
technology, information, and roles interact?
2. Business Architecture is a Critical EA Domain
Most critical EA domain
is the Business Architecture that allows the Application Architecture to be
functionally aligned, business information aligned by the Data Architecture and
finally quality serviced by the Technical Architecture.
·
Business
Domain drives other domains. Whatever framework(s) you take and whatever
number of domains you classify and put names on them - there is always one the common domain that drives others: This is BUSINESS DOMAIN and having necessary
information about how your business runs, what is its structure (or
architecture) define other domains (Systems or Applications, Security,
Technology, Data or Integration Domains).
·
EA is
measurable in terms of
-Overall Value delivered per iteration (reduced costs of duplication, overlaps in activities, time-to-market...),
-Value delivered to specific stakeholders (blueprint and solution save so much...)
-Overall Value delivered per iteration (reduced costs of duplication, overlaps in activities, time-to-market...),
-Value delivered to specific stakeholders (blueprint and solution save so much...)
3. The Success Criteria of EA Initiatives
There are the very low success rates of EA projects to satisfy
customers, EA may even have trouble identifying loyal customers besides
enterprise architects themselves. What are the success criteria of EA
initiatives, and what are tools or mechanisms to steering success?
(1) EA is measurable,
that is the one important purpose of EA Governance.
(2) EA has
deliverables, although it cannot be sure that they are universally accepted,
at least, they should benefit decision-makers or other EA users/customers with a tangible result.
(3) Those deliverables can be used in the next phase of
architecture work; EA deliverables are at a high level and will add more
granular details as diving deep into specific domain architecture at low
levels.
A forward and reverse traceability matrix can help to steer towards these criteria. As the EA initiative is taken up mostly in a top-down
approach, obviously in its first iteration, many of these initiatives will be abstract as
it is derived from the business values and goals set up by the business owners
and stakeholders. However, in subsequent iterations, these abstractions are
decomposed for realizations.
0 comments:
Post a Comment