August 6, 2003
In this issue:
* Enterprise Architects Obstacle Course Part II
* Enterprise Architecture News
* Arctec Group News: Arctec Group Progresses On New Saint Paul Office
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 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.
Previous issues are available at www.arctecgroup.net/views.htm
Enterprise Architecture Obstacle Course: Does Your Organization Overcome These Challenges?
The second installment of a two-part series discusses key factors that typically hinder the success of Enterprise Architecture (EA) programs. This month, we examine more tactical, execution-oriented challenges, many of which are more internal to the EA team or practice itself.
Too much overhead
Related to the staffing challenge mentioned last month, the perception and/or reality of imposing too much overhead on your organization can have similar causes: Architecture can play a number of roles in an organization based on the desired deliverables and outcomes (a spectrum of options from strictly decision-support to the absolute-buck-stops-here role), and if an organization does not explicitly discuss this, there typically won’t be either competency models developed, or process/deliverable models developed to staff against. It is difficult to be “lightweight” without clearly understanding the specific role/process/deliverable targets desired – managing the risk of this unknown naturally leads to heavier processes and too many non-value-added activities.
Inability to be pragmatic
If fortunate enough to have a collaborative relationship with business and other key stakeholders, it can be squandered by failing to architect within reasonable constraints (budget, time, ability to execute, etc.). People will soon either stop asking, or avoid contact. Architects need to assist in making pragmatic decisions or adjustments, and demonstrate how architectural pragmatism is more beneficial to the organization than “ivory tower” architecture.
Not coming to the table with a solution (the dreaded “Devil’s advocate”)
Related to previous point, the “devil’s advocate” typically fails to bridge the gap between the abstract business and architectural drivers to a solution or solution pattern that is achievable. Information technology professionals, not just architects, tend to be very analytical people. The unfortunate side effect of analytical people is the ability to “pick things apart”, and this is always easier than providing a solution. Aside from this generality, this trait often occurs with architectural professionals due to differing expectations: the architect assumes that by presenting a pattern that he/she is presenting a solution, and the business or development areas are expecting specific tool/language/platform/component identification that is more immediately actionable.
Another factor is usually the architect’s desire for including other dependencies to “get it right.” If these solutions/solution patterns have not yet been architected or communicated (and the resources are out of scope for the current project), this can create a “deadly embrace” that can bring progress to a halt, when the architect does not provide a reasonable roadmap of activities to solve the problem.
Failure to choose a model or metaphor
By model or metaphor, I am referring to architectural paradigms provided by research organizations, industry groups, or vendors themselves. A myriad of options exist that create specific terminology, phase breakdowns, artifact definitions, etc. for architecture programs. It is important to settle on your organization’s preferred method (often a customized hybrid), to have a common understanding and nomenclature for your company and clarified expectations of delivery. While most of these industry models contain similar elements, when mixing and matching content, the models can often appear contradictory.
Experienced Enterprise Architects familiar with these differing methodologies often understand the overlap and contradiction and can work with them implicitly, mixed terms and artifacts will confuse the message to their customer base and can undercut understanding and credibility. Also, great leverage can be gained by utilizing techniques that are mainstream to either your industry sector or the IT industry as a whole.
Premature focus on automation (if we just had this tool…)
Architects are not immune to the disease of asking for cool tools without first specifying requirements (understanding which processes and resulting deliverable artifacts will be effective in their organization and how a tool may support this). As with any selection, it is difficult to cull through the many architectural tools and repositories and make an effective judgment without a solid understanding of what you need. If desired deliverables are well understood and a market solution that fits your paradigm seems to be available, do not underestimate the effort required to implement – the architectural repositories can be extremely broad in scope, and require heavy input of baseline information to be effective. Prematurely focusing on the automation aspect can also create an unbalanced internal focus – beware alienating your customer by getting too wrapped up in a tool.
Failure to produce actionable deliverables (what do those architects do anyway??)
This point is easily a culmination of most if not all of the points above. With any role, clear accountability is needed to produce results; we all have a need to understand what is expected of us. If these waters seem murky, it is better to produce tangible examples to drive review/acceptance/collaboration and ultimately adoption, rather than waiting for clarity (that will rarely appear). It can be a futile exercise to attempt to gain support and understanding of abstract concepts without tangible deliverables that demonstrate impact. Without action that produces results, there is no credibility and demonstration of value, and therefore ultimately no EA program.
Enterprise Architecture News
Novell Acquires Ximian
Smart move by Novell. Ximian is one of the two dominant players in the Linux desktop space with their Ximian desktop product.
The C# Design Process A Conversation with Anders Hejlsberg
Artima's Bill Venners and Bruce Eckel (of "Thinking In Java" fame) interview Microsoft's Anders Hejlsberg on the process of designing C#. Hejlsberg has a number of language innovations to his credit previous to his work on C#, including Turbo Pascal and Delphi.
BEA offers Aspect-Oriented Programming framework
Although the concept of aspect-oriented programming (AOP) has been around for awhile, it has been anointed as the "next big thing." Now the tools and products markets are begining to deliver on the promise of AOP. AOP is not a direct replacement of Object-Oriented programming (OOP), but is complementary. Specifically, AOP is geared towards addressing "cross-cutting" concerns which in turn enables a more architecturally-focused system design. Some of our clients may recognize the modularization of common architectural services that AOP endorses.
Aspect Oriented Software Development Home Page
Aspect-Oriented Programming (AOP) System for WebLogic
Linux Security Advances
IBM and SuSE joined forces to create the first Linux distribution that meets the internationally-recognized Common Criteria Security Certification
Common Criteria Home Page
Apart from cracking the German Enigma code during World War II. A new book asserts evidence that suggests British and American codebreakers were collaborating to crack Russian codes in 1946
Edsger Dijkstra Manuscripts
August 6 is the one year anniversary of Edsger Dijkstra's death. He made major contributions to the field of Computer Science, including the famous paper "GOTO Considered Harmful." A group of volunteers has scanned and assembled over 7700 pages of his handwritten and numbered documents which he sent to colleagues.
Have your say
Agree? Disagree? Insufficient data to judge? Email us at email@example.com, we want to hear from you.
Arctec Group News
Progress continues on Arctec Group's new Saint Paul office. The renovation is complete for the office space in the historic J. Walter Stevens' designed Railroader Printing Building (which once housed James J. Hill's printing presses). Opening date is planned for September.
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 firstname.lastname@example.org from the email account you would like to receive the newsletter. Please include the word "subscribe" in the subject or first line of the email.
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.