July 7, 2003
In this issue:
* Enterprise Architects Obstacle Course
* Enterprise Architecture News
* Arctec Group News: Arctec Group New Office coming soon
Arctec Group is an architectural services company focused on Enterprise
Architecture issues. With this newsletter, we aim to serve our clients,
partners, and colleagues by providing our view on current issues and
best practices in Enterprise Architecture as well as aggregating
interesting news from around the globe.
We hope you find the newsletter useful and enlightening. We would like
to hear your thoughts on current affairs and ways we can improve this
offering. If you would like to unsubscribe to Arctec Views monthly
newsletter, simply send an email to email@example.com from the email
account you would like to unsubscribe. Please include the word
"unsubscribe" in the subject or first line of the email.
Previous issues are available at www.arctecgroup.net/views.htm
Enterprise Architecture Obstacle Course: Does Your Organization Overcome These Challenges?
The first installment of a two-part series.
While all businesses have a certain degree of uniqueness, often it is dealing with the common challenges that make-or-break architectural success. This article is the first of a two-part series discussing key factors that typically hinder the success of Enterprise Architecture programs. The first installment will discuss common strategic hurdles, while next month we will focus on challenges of a more tactical nature.
Failure to translate business strategies to architectural drivers
Distilling architectural requirements from business strategies is extremely difficult. However difficult, the importance of these architectural requirements far outweigh the challenge in defining them. Understanding this linkage provides the foundation for the “contract” between the business and Information Technology departments, and shapes activities accordingly. As few business plans or budgets include explicit technical drivers, this is more effectively done in a collaborative discussion, as more Q&A is typically needed to get the tangible information used to drive technical decisions.
There are often key business planning cycles with formal or informal output, and it is key for IT to participate versus strictly receiving the output. However, if by participating IT turns strategic business planning into a detailed requirements-gathering exercise, the business will quickly get frustrated and progress will be hindered on both fronts. It is critical to have concise questions about pre-determined architectural drivers, for example targeted financial or cycle time goals, audience/user/target market scope, volumetrics, availability assumptions, etc. This strategy facilitates expedited mapping to architectural drivers and confirmation/validation with the business - and allows additional details to be discovered during the program and project definition sessions that have been scoped with these drivers.
Failure to understand the business rhythms
Closely related to the previous point, this is more specifically aimed at occurrences of ignoring reality. Exceptional architects understand the rhythms of the business and utilize this as a handle to aid progress and push planning of specific programs at the right time. Poor architects are trying to instigate strategic planning in the middle of a critical execution cycle, which can destroy credibility even if the activities are technically correct.
Poor program planning/prioritization (failure to start/stop the right things)
Effective IT organizations manage priority work by defining programs (a series of related projects to accomplish a goal) that are driven by business priorities as described in the previous points. To effectively drive architecture, the same defined business priorities are needed to provide the overall decision-making context, and defining the right programs and corresponding technical roadmaps should be a collaborative process with the business, program management, and architecture teams. The challenge for the architecture team in the program planning exercise is to insure that the program plans contain the right technical building blocks to meet the business needs, and that the building block projects are prioritized for execution in the appropriate phase of the program with the proper dependencies (the right thing at the right time). If a program plan is too heavily weighted with either technical or business priorities, it will almost certainly fail to meet financial and/or quality expectations.
Aside from the initial plans, to run an effective business of any sort, an organization must be nimble enough to make trade-offs when unplanned challenges arise. The key to making effective trade-offs is to understand both the immediate and longer term business goals and priorities, and have defined programs that reflect these targets. These goals, priorities, and programs provide the context to the subsequent architectural decision-making – lack of context reduces the ability for targeted change, causing staff to rely solely on past experience and industry knowledge. The result is often a default mentality in which both potential short-cuts and long-term commitments are dragged to the “middle-of-the-road”, causing over-analysis on work that should truly be disposable, and not enough commitment to work that is truly strategically aligned.
This middle-of-the-road syndrome can also cause dilution of resources across too many projects, leading to mediocre results and pervasive lack of “completion”.
Lack of agreed-upon “value measurement”
Collaborative planning between business and IT constituents has many outputs, but key success or value metrics are important enough to mention on their own. An organization’s maturity can often be assessed easily by reviewing the metrics in place (or lack thereof). Many of the challenges discussed in this article speak of decision-making context, and the metrics provide the agreed-upon measurability of that context. Effective architecture programs implement and baseline key metrics to guide and report on progress, often developing dashboard-like views to communicate with other IT and business units. Two points of advice here: 1) it is better to have a few well-understood metrics that reflect business and IT architectural drivers, than to develop exhaustive measures of items that do not effect decision-making behavior, and 2) it is good to have a mixture of customer-facing and internal metrics.
This applies to having inappropriate or irrelevant roles, inappropriate staffing levels, or inadequate staff. The last point does not usually mean unqualified or bad people, but often miscast, or not positioned to succeed through a number of reasons. There are many valid industry methods to organize an architecture program and define the corresponding roles. Architecture can play a number of roles in an organization based on the desired deliverables and outcomes (valid architecture program models are a spectrum of options from strictly decision-support to the absolute-buck-stops-here role). If an organization does not explicitly discuss and understand this, then there typically are not either 1) competency models developed to staff against, or 2) process/deliverable models developed to staff against. These tools not only assist in defining and filling the appropriate roles, but help to set clear expectations for performance. Without a specific understanding of the role you desire architecture to play, it is often a loosely-defined family of job descriptions at the top of the technical career path, that may strictly attract long-standing technical resources that do not desire a management track.
Lack of decision-making authority and accountability
Assuming the proper business drivers and priorities provide a meaningful context, it is still necessary for architecture decisions to “have some teeth”. This is not stated to imply an adversarial tone, but rather to ensure that there is clarity of accountability and responsibility. As mentioned, there are many appropriate models of architecture management, and these models should specify the decisions owned in the architectural domain. It is critical that the model is agreed upon by your organization, or what occurs in practice will not reflect your desired outcome. As discussed at length in previous points, it is equally important that architectural decision-making criteria is well understood and driven by the business and technical priorities, or even if appropriate decision-making authority exists it will soon be circumvented or taken away.
Lack of appropriate ties to project and development/delivery process
Depending on which model you deem effective for your organization, architecture programs differ in their level of detail specification feeding application and infrastructure development. Regardless of the level of detail, corresponding checks and balances need to be maintained to insure 1) what is specified is in fact delivered, 2) there is collaboration regarding trade-off decisions that may arise, and 3) learning/discoveries made during the delivery process can impact the architectural direction if appropriate. Often involvement is strictly on the front-end of the project, or the other extreme of becoming immersed within the delivery/implementation phase, either if which is not effective.
No incentive to deliver
There is always healthy pressure between those that are in operational delivery positions and those that are in planning-oriented positions. Frequently planners are discounted as being too disconnected from the real world of product/service deadlines, customer demands, share price, etc. As the saying goes, “follow the money”. If you can ask the question of an architect “what are you paid for” and part of the answer is not “to deliver quality systems on time” or something similar, delivery is not foremost in their mind. The key is to strike the difficult balance of architecting the future while meeting the business pressures of today, and remaining grounded in the fact that there is no future if you fail to deliver today. As a side note, people often become more well-rounded architects if they have had some experience in an implementation/operational mode.
Next month: Tactical hurdles facing Enterprise Architecture.
Enterprise Architecture News
The industry is already beginning to write the post mortems on SCO on
Tim O'Reilly: Software Licenses Don't Work
Insightful look at licensing from esteemed publisher.
J2EE serves over 400 million transactions/day for eBay
When White Hat Hackers Go Bad
This is from Fortune, but reads like a cross between a Business week article and a mystery novel.
Post merger analysis: What's ahead for Palm
Calculating the Cost of Distributed Computing
Austin, TX launches Linux thin client pilot
Open Source Database Analysis. This piece has some information on SAP's
decision to "open source" their enterprise class DB. Will other vendors follow suit by "open sourcing" components within their product lines?
Have your say
Agree? Disagree? Insufficient data to judge? Email us at
firstname.lastname@example.org, we want to hear from you.
Arctec Group News
Arctec Group plans to open a new office including conferencing facilities in the historic Lowertown section of Saint Paul. Stay tuned for opening date.
Arctec Group: Strategic Technology Blueprints
Arctec Group Newsletter is a free monthly newsletter. If you would like
to subscribe to Arctec Views, simply send an email to
email@example.com from the email account you would like to receive
the newsletter. Please include the word "subscribe" in the subject or
first line of the
If you would like to unsubscribe to Arctec Views monthly newsletter,
simply send an email to firstname.lastname@example.org from the email account you
would like to unsubscribe. Please include the word "unsubscribe" in the
subject or first line of the email.