Architectural Services | Resources | Views | Contact Arctec Group

Arctec Views

January 10, 2005

In this issue:

    * Architectural Hunting & Gathering
    * Enterprise Architecture News
    * Arctec Group News:
    Web Services Security Briefing
    Collaboration in a Secure Development Process published

*************************************
Arctec Group remains in high demand on projects across the US (a contributing factor to recently less frequent Arctec Views). With this Arctec Views 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 the Enterprise Architecture landscape.

*************************************
Architectural Hunting and Gathering: Looking for *-ility force multipliers

One of the main duties of the architect is to harmonize functional requirements (e.g. what should the system do and for whom), and its non-functional requirements (e.g. what supporting foundation characteristics are desired in terms of "ilities" like usability, reliability, and security). An ongoing challenge in the architecture field is the extent to which the architect is able to get a requisite amount of non-functional properties built into the design and end product, insuring that the software ships on a solid foundation from both a business and user viewpoint. Since not all non-functional requirements generally make it into the final product, the next question is what ilities have the most impact. Assume for a moment that all ilities are created equal, which their practitioners will all assure you that they are not (Role based access control cures starvation! Death before difficulty in usability!). Thinking about the non-functional requirements together in terms of a coherent architectural foundation layer provides opportunities to see force multipliers.

Each ility comprises a vertical slice with its own set of core disciplines, analytic and design techniques, and metrics. The job of the architect is to assist the ility experts in decomposing each vertical slice and synthesizing these vertical slices into a holistic foundation that elegantly supports the functional requirements and the more abstract non-functional requirements.

The ility chessboard
Ilities consist of elements like security, usability, reliability, and performance. In many cases an increase in one ility area will degrade another (for example, parsing every xml document three times for security reasons degrades transaction performance). For this reason, a relative weighting of these factors is in order. In many projects, one or two ilities may get elevated to a high status (for one reason or another) and may drown out the other non-functional requirements to the detriment of the whole. Assuming that value proposition arguments provided by the proponents of each ility community are true, then this is not a zero sum game and elevating, say, performance to the highest priority at the cost of every other ility has impacts which should be quantified and studied.

Deeper than relative weighting, the architect should also facilitate finding areas where the ilities agree and complement each other. By digging into the details of the ilities disciplines, the architect can uncover areas of overlap in terms of desired synergistic system properties. In other words, one ilities wish list may have elements that both contradict and support other ilities. The job of the architect is to find the blend of impactful supporting elements from the ilities wish list and meld them into a coherent whole.

To the extent that each ility has to make its own business case seen on an individual level, they may rationally lose out to a given business feature. However, an architecture that supports, say simplicity, widely valued across the ility communities in the face of rampant featurism, may make a defensible case when looked at in the total picture. For example, simplicity is a desirable characteristic from both a security and usability viewpoint, but successfully making the case for either individually versus a given feature may be problematic. The architect's mandate is to identify the characteristics that are most valuable across the ility landscape and drive value across the vertical slices. Only then can the foundational elements be assessed against functional requirements to reason about architectural merits, and insure delivering a platform that will support the features in the manner ultimately desired. For example, the most effective way to increase security in a software system generally is not to have a design debate with business stakeholders about the relative merits of a security mechanism versus a feature set. The context of the discussion must change by collaborating with other ility disciplines, and demonstrating the combined business impact of the functionality supported by a robust foundation.

-Gunnar Peterson

*************************************
Enterprise Architecture News

Kim Cameron's Laws of Identity
Kim Cameron, of Zoomit fame, is currently Microsoft's architect for identity projects including Active Directory. From the Laws of Identity: "People who work on or with identity systems need to obey the Laws of Identity. When we don't, we leave behind us a wake of reinforcing side-effects that eventually undermine all resulting technology. The result is similar to what would happen if civil engineers were to flaunt the law of gravity." So far, Kim has released 5 of his 7 laws.
http://www.identityblog.com/stories/2004/12/09/thelaws.html

Robert X. Cringeley's Predictions for 2005
Apple ascendant; Sun on the wane
http://www.pbs.org/cringely/pulpit/pulpit20050107.html

Security and the Application Development Process
"RFG believes that writing secure application code is an integral component of the overall enterprise security architecture, and, unless application requirements are identified up front, it is difficult for the development process to implement the required levels of security"
http://www.csoonline.com/analyst/report3068.html

Baking Security into the Development Process
The view on application security from Oracle
Article here

And lastly, the wait is over: finally, a $50,000 consumer PC
http://www.theregister.co.uk/2005/01/07/couture_pc/

*************************************
Have your say
Agree? Disagree? Insufficient data to judge? Email us at views@arctecgroup.net, we want to hear from you.

*************************************
Arctec Group News

Gunnar Peterson presents on January 18 at Minnesota Information Systems Security Association. The Topic is: Web Services - A Hacker's Best Friend? Web services software is circumventing traditional security controls like firewalls: why you should care, what you need to know, and what you can do about it.

Industry analysts predict that in the next 2-3 years the majority of enterprise applications will be Web Services enabled. This session focuses on Web Services software security architecture in real world enterprise scenarios. The threats that emerge from the new paradigm of Web Services and Service Oriented Architectures (SOA) requires a shift in the security mindset to effectively manage business risk. This session takes a proactive approach to security posture and examines organizational, process, and architectural solutions framework towards improving the software security in your organization. For information on attending this meeting visit: http://www.mn-issa.org/html/chaptermeetings.html

Security in the Software Development Lifecycle
Collaboration in a Secure Development Process, Parts 2 and 3, by Arctec CTO Gunnar Peterson are now available online. This three part series featured in Information Security Bulletin (http://www.chi-publishing.com) examines a proactive approach for security, development, and business teams to partner in the development lifecycle to make intelligent choices about security tradeoffs, business risk, and features. Order through Information Security Bulletin or view the articles at: www.arctecgroup.net/articles.htm

*************************************
Arctec Group: Strategic Technology Blueprints www.arctecgroup.net

Copyright © 2005 Arctec Group, LLC All Rights Reserved