Firebrand Architect®

An expert is ...

2008-07-21T18:44:00.002-04:00

My definition of an expert in any field is a person who knows enough about what's really going on to be scared.
- PJ Plauger

Constantin K.
Firebrand Architect™
www.SoftwareArchitectures.com

Tough crowd: architecting in a shadow of a challenged project

2008-04-28T22:56:00.002-04:00

The human feelings is a decision making variable that software architects must consider when architecting or more importantly – when strategizing a software system. This is especially important in environments where users have technology based scars.

Situation: Users had (or still have) a bad experience with implementation, deployment, and support of an enterprise grade solution. The system was adopted by a large (7000 people) organization through a mandate – people use it on a daily basis because they are forced. This brute force approach has done a tremendous damage to users’ trust and any new IT investment will be severely challenged.

Potential solution

1. Recognize the pain your future users are feeling right now. Study the situation and learn their existing environment. Understand the challenges of that system – you may face them as well.

2. Clearly understand the business problem you will solve with a software solution. You must, absolutely must, get different perspectives on the problem from a full range of stakeholders – from executive owners to the solution end users. You must be convinced that this solution will solve a business problem.

3. Go an extra mile when documenting the quality attributes of the system to demonstrate through scenarios how your system will not have the frustrating elements of the existing system that scarred the users’ experience. Consider paying an extended attention to the usability quality attributes.

4. Architect your solution so that initial implementation steps can demonstrate progress early. Create a special view of the architecture (an abstract component connector view will work well) targeting your non-technical user base.

5. When possible consider using software you can configure (e.g. COTS packages) to show progress early and often.

6. Conduct demos to the right audiences: the user base influencers. Demonstrate through actions how your approach to architecting and implementing is different than the experience your users had. Especially pay attention to the pain points your users have suffered with another solution. Ask for feedback. No. Demand feedback.

7. Remember that even if you get the architecture “right” it may be implemented wrong. On project you must stay fully engaged in the implementation and monitor conformance with the architecture as if your reputation was on the line. Actually, your reputation is on the line.

In this type of a situation it may be appropriate for an architect to pay a lot of attention to the user touchable interfaces (i.e. UI) before immersing one’s attention on creating a solid skeleton of a system that captures conceptual integrity of the system.

Do you have an experience to share where human perception played a role in your architecture related thinking? Leave a comment.

Constantin K.
Firebrand Architect™
www.SoftwareArchitectures.com

How mature is the software architecture discipline?

2008-04-24T01:10:00.006-04:00

In 1996 Professors David Garlan and Mary Shaw of the Carnegie Mellon University published an influential book: “Software Architecture – Perspectives on an Emerging Discipline”. In chapter 1 the authors discuss a model for the evolution of an engineering discipline. The diagram can be found here.

Before discussing the diagram let’s establish a few key concepts. With respect to maturity of engineering disciplines based on pure sciences (e.g. chemical engineering) the software engineering discipline and to a greater extent software architecture discipline is generally considered to be very immature. But why? The authors state that “engineering practice enables ordinary practitioners create sophisticated systems that work … reliably.” Has the software architecture reached this state?

It’s important to note that engineering discipline practitioners make the bulk of money by solving routine design problems. Routine design aims at “solving familiar problems” and designing solutions by using the knowledge base from previous projects and experiences (e.g. an e-commerce shopping cart site). Innovative design aims at solving original and unique problems, such as controlling an unmanned helicopter through a remote control center. It’s important to note that with software architecture discipline the bulk of the money is made solving routine problems by ordinary practitioners.

So how do engineering disciplines evolve?

The engineering disciplines evolve from ad hoc state in two steps. Initially, talented and passionate amateurs pioneer the discipline. They achieve their goals by all means necessary – usually irrationally using available resources. Later the routine production occurs. With time the need for advancement arises and supporting science for an engineering discipline emerges. The maturing science eventually turns into a “professional engineering practice,” where science will become the main driving force of a discipline.

What will it take for the software architecture discipline to become mature? This question will be addressed in the future post.

Other ideas to think about: if software architecture discipline is not based on hard science at its higher levels of abstraction, will it ever reach the same level of maturity as a civil engineering?

Constantin K.
Firebrand Architect™
www.SoftwareArchitectures.com

Software Architecture is about people

2008-04-24T00:03:00.001-04:00

At its core the software architecture discipline is about people and our obstacles are a figment of our imagination.

Constantin K.
Firebrand Architect™
www.SoftwareArchitectures.com

Microsoft’s Architecture Journal 15

2008-04-23T00:50:00.000-04:00

The latest issue of the Microsoft’s Architecture Journal is bound to rekindle the topic of maturity and purpose of the software / enterprise / technical / infrastructure / data architecture discipline. The issue is fresh off the press. Microsoft is correctly anticipating the onslaught of responses by setting up a special discussion forum. As of writing of this post the forum is not yet active, but once it becomes active the phrase tra-ta-ta-ta-ta will take on a whole new meaning.

Constantin K.
Firebrand Architect™
www.SoftwareArchitectures.com

Software Architecture Assessment

2008-04-23T00:01:00.000-04:00

Assessment of software architecture is necessary to judge its utility and applicability to the goals a system aims to achieve. Every architecture design should be assessed by a non-partisan resource, but this practice has been adopted only at organizations with a very mature software engineering processes. There are no industry wide accepted methods for evaluating software architecture, but the Architecture Tradeoff Analysis Method (ATAM), developed by the SEI, is a well structured & rational approach for conducting architecture assessments.

Benefits of a structured tradeoff analysis method

The principal benefit of the Architecture Tradeoff Analysis is an ability to see if a proposed overall software structure will live up to the user expectations. The tradeoff analysis helps one understand the strengths and weaknesses of a system. The ATAM method not only helps evaluate the current system architecture, but also helps with the design of architecture for a new system. This methodology helps designers to ask the right questions and solve critical issues early on in the project. Additionally, selecting the right degree of quality for a specific system fully utilizes the money spent by the customer, as the money spent in any one particular area of the system will be justified.

The ATAM process helps developers discover tradeoffs and sensitivity points

The tradeoff points are defined as the dependencies between attributes. The sensitivity points are the areas of the system that will be significantly impacted if system architecture is changed. The tradeoff points are the breeding ground for the sensitivity points, because when architecture changes the connections between different attributes changes as well.

One of the more obvious tradeoffs is the relationship between performance and security quality. Often the security quality is achieved by compromising performance; this is not a surprising statement as it’s general knowledge that making something secure requires a special effort. Even outside of the architectural context, securing a door in a house requires a purchase and installation of a lock – and that’s only the initial costs. The effort required to lock and unlock the door each time it’s open/closed is an additional cost/effort element. In this out of context example performance of the door can be increased by not installing a door lock. With no lock there is little security, as anyone can open the door with no trouble. The tradeoff points in this example are the presence of lock(s) and the speed at which a door may be opened (perhaps for security reasons it can only be opened at 1 foot per hour).

Key sensitive points are like the gauges that must be monitored by an architect each time a change to a software system is considered on an architectural level.

Do you evaluate your software architecture?

At the end of the day a systemic architecture evaluation method is up to the architect to decide. What matters is that an architect has a way to judge whether architecture is the right fit for a business problem at hand. Other evaluation methods exist and serve various purposes: SAAM, ALMA, FAAM, CBAM. Some even use this assessment form.

Post a comment if you evaluate software architecture. How do you do it?

Constantin K.
Firebrand Architect™
www.SoftwareArchitectures.com

Boundaries between "Architecture", "Design", and "Implementation" formally defined

2008-04-19T18:20:00.000-04:00

Insightful paper by Rick Kazman & Amnon Eden, presented at ICSE 2003, that defines the boundaries between "Architecture", "Design", and "Implementation" by formalizing the ‘Intension and the Locality criteria, which imply that the distinction between architecture, design, and implementation is qualitative and not merely quantitative.’

Basic understanding of formal notation (esp. Zed) is necessary for enriched reading experience.

Download the paper from SoftwareArchitectures.com or SEI.

Constantin K.
Firebrand Architect™
www.SoftwareArchitectures.com

Microsoft's Architecture MVP Changes

2008-04-18T23:24:00.001-04:00

In late February of 2008 Microsoft dissolved the Microsoft Architecture MVP award as part of realignment of the MVP program to be more product oriented. Dissolved is a wrong word … so read on. This came as a surprise to many award recipients - including myself – who lost a “nice to have” title. This development, however, had a very positive impact on the Architecture MVP community, because it forced the architects ask themselves some hard questions about their role in the community and the role Microsoft plays in the software architecture discipline.

This post features some highlights from the ferociously bubbling listserv.

At first there was confusion. Participants understood the reasoning behind moving towards a product oriented approach, but they couldn’t fathom the disappearance of the architecture competency. Then there was anger – well summarized by one of the participants: “I believe the shutdown of the MVP Architect program is just one more piece of evidence that … Microsoft does not appreciate the role of the architect in driving large buy decisions.”

Then a word of wisdom came from Simon Guest. In order for the MVP program to grow the structure has to change. MVPs will be aligned to a product, but will be able to select a discipline such as architecture. Simon then called for an open forum at the MVP summit in Redmond on April 15^th.

Identity crisis started to emerge – some participants, including Martin Fowler, voiced their reserved opinions about the value of the MVP award. Valid questions arose – why do architects communicate so little with each other? What role do architects play in organizations? What do they do for Microsoft? The consensus was clear – although there is a clear need for robust architecture communities the MVP award infrastructure didn’t make individual architects feel part of a single unit.

Finally discussion merged onto taking proactive steps to define the scope and purpose of the group. Familiar questions arose: how do we define different types of architects? What are the definitions of architecture and architect? Should we just take some definitions from IASA? Microsoft has established a work space where the discussion of these various topics will commence.

There are no clear answers, but there are good questions – Microsoft is moving in the right direction albeit at its own pace.

Constantin K.
Firebrand Architect™
www.SoftwareArchitectures.com

Frank Lloyd Wright

2008-01-25T20:07:00.000-05:00

Frank Lloyd Wright, one of the most famous American [building] architects of all time, worked on over 500 structures and left a few notes of wisdom for us to consider. While the comparison between software and building architecture breaks down pretty quickly, the quotes below apply to both disciplines.

A great architect is not made by way of a brain nearly so much as he is made by way of a cultivated, enriched heart.
All fine architectural values are human vales, else not valuable.
An architect's most useful tools are an eraser at the drafting board, and a wrecking bar at the site.
Every great architect is - necessarily - a great poet. He must be a great original interpreter of his time, his day, his age.
Form follows function - that has been misunderstood. Form and function should be one, joined in a spiritual union.
Get the habit of analysis - analysis will in time enable synthesis to become your habit of mind.
Less is only more where more is no good.
The architect must be a prophet... a prophet in the true sense of the term... if he can't see at least ten years ahead don't call him an architect.
The architect should strive continually to simplify; the ensemble of the rooms should then be carefully considered that comfort and utility may go hand in hand with beauty.
The truth is more important than the facts.
"Think simple" as my old master used to say - meaning reduce the whole of its parts into the simplest terms, getting back to first principles.

Constantin K.
Firebrand Architect™
www.SoftwareArchitectures.com

Static, Runtime, Physical

2008-01-23T23:26:00.000-05:00

For the spring 2008 semester I function as a distance education instructor for the Principles of Software Architectures course offered by the School of Computer Science at the Carnegie Mellon University through the Institute for Software Research International. As I reviewed the course I fondly remembered the lectures by Prof. David Garlan and Tony Lattanze while pursuing my Masters in Software Engineering (IT) degree some years ago. At the same time I reflected on the architecture representation practices employed on some of the recent projects I’ve reviewed and sadly the state of affairs is looking pretty grim.

It is still common to see software architecture designs mix incongruent design elements together, such as combining message flow process with a class diagram. As a gentle reminder, architecture of a software system is represented through a number of views that describe some angle of a system. There are many different views that can be chosen by an architect to represent some aspect of the system (e.g. process view, deployment view, decomposition view, etc.). No matter what view an architect chooses to document some aspect of architecture it’s critical to understand that most views can be classified into static, runtime, and physical. It is absolutely critical to maintain conceptual integrity of a given view; otherwise you may be comparing apples to oranges. If this is new to you read a copy of Software Architecture in Practice, Second Edition, take this course from Carnegie Mellon, or take a class from the Software Engineering Institute.

Constantin K.
Firebrand Architect™
www.SoftwareArchitectures.com

Evolving Opportunistic Solutions

2008-01-20T23:15:00.001-05:00

Opportunistic projects (software solutions) are the essence of the progress in all organizations. These projects provide valuable ad-hoc gains in productivity to the people who need help the most. Such projects usually don’t have a formal budget, have one or a few people running it, and usually reside outside of enterprise architecture environment or go against the formal way of doing things. But these projects exist because they provide the benefit the core IT organization cannot.

One example may be auto generation of pre-canned reports for a loan processing clerk. In this case an existing FICO score provides good information about the risk level of a potential borrower, but a loan procession clerk may get an additional level of insight, and reduce risk to the bank, by looking into additional publically available information. Usually opportunistic solutions target a small specialized niche, such as pre-canned reports for farm machinery loans. But as loan officers across bank divisions talk to each other, they find out that these reports are insightful for other loan types, and eliminate the need to do manual research. Now all loan officers want these reports to be included as part of their loan application paperwork. Loan division chief requests the opportunistic software solution owners to provide reports to everyone. Will this work?

A responsible software architect who recognizes this situation needs to act fast. There are many red flags in this scenario that may turn a well respected idea into a disaster. First, it should be clear that unless the designers of the opportunistic software solution thought about scalability and extensibility during design it may not be possible to produce more reports without rethinking entire approach. Perhaps the solution taps into an already overtaxed database system that goes offline periodically. Secondly, the growth problem may not only be technical in nature. May be the business process supported by the software solution is not scalable. It may be that the software generates reports and emails them to users automatically, but requests for reports are being processed manually. Perhaps the reactive response to support the requested increase in demand would be to add staff and throw hardware at the problem. That may last for some time, if system allows multiple users, but eventually the opportunistic solution will require features that can only be obtained from enterprise services (e.g. SMTP service, enterprise auditing, directory services, etc.).

The moral of the story: build on success of opportunistic solutions. Recognize patterns, analyze change impact, educate solution owners on the natural evolution of successful opportunistic solutions and on the differences between ad-hoc and enterprise solutions, understand how requested change fits into the existing and future organizational enterprise architecture, and finally show the solution owners that the demand for their service will only grow with time.

Constantin K.
Firebrand Architect™
www.SoftwareArchitectures.com

Edward Hopper - Communicating the Essence

2008-01-19T18:25:00.001-05:00

It’s the architect’s job to decide and communicate which quality attributes need to be emphasized in order to achieve the overarching mission of a solution. Similarly the iconic American artist Edward Hopper, in his paintings, captured the essence of a scene while abstracting the negligent elements of the situation.

In painting Haskell’s House you clearly see that the artist chose to omit the wires from the electrical poles. The busy harbor behind the house is not depicted in the painting: the core emphasis is on the house. Also notice how the sun rays draw your attention on the house and you can almost forget about the mundane details of trees, landscaping, and electrical poles. A software architect has a similar job: capture the big picture (e.g. security, environment constraints, composition of services), but note the critical solution qualities (e.g. usability, performance).

In the infamous painting, Nighthawks, Edward Hopper uses light and shadows to concentrate viewer’s attention on the situation in a dinner. Notice lack of pedestrians, cars, or any other artifacts that would detract from the developing situation inside of a dinner. The viewer may dully acknowledge the presence of outside, but all the attention is concentrated on what is happening on the inside. Similarly an application architect that works in a mature design environment simply needs to acknowledge the presence of certain assumptions, but concentrate his work on the essence of a solution.

The 1940 painting Gas shows a lonely attendant at a gas station. There are no cars fueling or on the road. The obvious, cars, is not commuicated.

If you ever have a chance to see a collection of Edward Hopper’s paintings do not miss that chance. A closer look at the paintings can be found here.

Constantin K.
Firebrand Architect™
www.SoftwareArchitectures.com

Enterprise Standards

2008-01-12T15:00:00.000-05:00

What kind of hardware & software environment exists at company Foo and how do they handle similar challenges? How will organization Foo evolve over time? Few organizations publish their enterprise architecture specifications; after all, a refined purposeful architecture is a competitive asset. But some organizations publish such information. If you search for MS Word or PDF documents for keywords such as “Enterprise Architecture principles”, “enterprise standards”, “to-be EA”, you will find a few valuable resources. One example is an IT Standards document for the US state of Kentucky. The freshness of the resources will vary, but discovering and learning from other organizations is a good way to gain new perspective and judge your organization’s software and enterprise architecture approaches.

Constantin K.
Firebrand Architect™
www.SoftwareArchitectures.com

Engineering elegance

2007-12-19T23:59:00.000-05:00

I came across this quote on definition of engineering elegance by a French aviator and author Antoine de Saint- Exupéry: “A designer knows he has achieved perfection not when there is nothing left to add, but when there is nothing left to take away.”

Is this statement applicable to software architecture? Aren’t architects constantly trying to add features that fulfill more and more functional and non-functional requirements? Aren’t multiple layers of security always good? Wouldn’t installing a .NET framework 3.5, for example, is better than .NET 3.0, because it has more features?

Perhaps those who see the power in this quote are the architects who are able to truly understand the essence of a business problem; it is those who can skillfully control the scope. But is this applicable to the software architecture domain as it stands now?

Constantin K.
Firebrand Architect™
www.SoftwareArchitectures.com

Software Architecture Conferences and Events

2007-12-16T22:58:00.000-05:00

The Software Engineering Institute maintains a comprehensive list of "upcoming conferences, workshops, and calls for participation that explicitly include "software architecture" among their topics of interest." This is a good place to start if you're looking for an opportunity to share thoughts with like minded individuals outside of your immediate circle of software architecture contacts. Research each event with care, as different user communities look at architecture from a different lens.

Constantin K.
Firebrand Architect™
www.SoftwareArchitectures.com

Technical and Business Architecture

2007-12-15T15:11:00.000-05:00

If architecting was only about solving a technical problem, then this discipline would be strictly under the computer science domain. What makes software architecture a child of the software engineering domain is the fact that an effective solution needs to solve business problem or achieve a mission.

It’s clear that an architect has to work works very closely with all stakeholders in order to understand the root of the problem for which a solution has been envisioned. There are two core qualities that an architect must exhibit. First, an architect must have an implementable vision of the whole concept from start to finish (if you don’t who will?). Second, an architect must intelligently question the business problem that a customer is trying to solve. This is very important, because this will minimize the risk of the solution not fitting into the existing (or future) technical and business infrastructure.

In mature organizations both software architects and business analysts speak a common language and work jointly to make sure a solution supports a business problem. In other organizations the burden often falls on the software architect to make sure that a solution design exhibits conceptual integrity from the business point of view. It’s not uncommon to have a group of business stakeholders individually represent what they want to see come out of the solution. But someone (business architect role) has to take ownership of the discrete needs and integrate them together into a comprehensive plan. Not every software architect is capable of deriving the root cause of a problem, and that’s OK. But a mature software architect would know when to bring in help to enable him to design the right solution.

Due to constraints thorough analysis is not always possible. This is where an architect must make a judgment call and make progress based on the known factors. In such situations it’s imperative to document risks and limitations of the solution so that the final result is judged against this segment of time.

Constantin K.
Firebrand Architect™
www.SoftwareArchitectures.com

Selecting COTS software under pressure (Forrester and Gartner)

2007-12-14T00:18:00.000-05:00

This happens on many projects: everyone agrees that the core of a solution (e.g. workflow engine) will be purchased instead of built from scratch. This is an absolutely rational decision for most enterprise applications. The next question is which vendor to select.

The rational approach is to identify the core functional requirements and key quality attributes that the solution must exhibit. This is an absolute must; because without understanding what you need you will not be able to objectively judge your options. The criteria on which you should evaluate you COTS software candidates must be granular and quantifiable to the degree that makes sense. Each criteria element needs to be weighed against all other chosen consideration elements so that all weights add to a whole. E.g. In case of workflow COTS software the number of concurrent workflow processes that the solution must support has to be at least 400 and this criterion has a 15% importance in relation to other selection elements.

The next step is to conduct evaluation of the market space for available vendor solutions. A number of solutions will not meet the top selected criteria based on the marketing information from the vendor, but few will emerge as potential candidates. Since COTS software will be an integral part of the solution a targeted proof of concept should be implemented and results judged against the established criteria. The outcome of the test along with other evaluation criteria is used to make an objective and rational decision.

If a decision on the COTS software absolutely has to be made in a period of time that doesn’t allow a proof of concept, then you should buy the intelligence from a third party that has done COTS software evaluation for you. Both Gartner (Magic Quadrant) and Forrester (The Forrester Wave) provide analysis of various COTS products that fulfill a particular segment of business applications (e.g. BPM tools). Each vendor solution is evaluated against a wide range of criteria. These reports provide very valuable insight, but without objectively understanding the needs of the solution you’re architecting it’s not possible to fully utilize the insight provided by a third party.

In general a Gartner, Forrester, or another 3^rd party report should be used in any COTS software evaluation whether you’re pressed for time or not.

Constantin K.
Firebrand Architect™
www.SoftwareArchitectures.com

Diplomacy

2007-12-13T00:01:00.001-05:00

As an architect you’re often get placed in uncomfortable situations. One of such scenarios is facing the architect of a working system that you’re tasked with replacing.

In this scenario your organization has an existing legacy system that still does a decent job of supporting the current needs of the business. The executives funded your project, because the legacy system cannot support the evolving business needs. You’re up to a real challenge. By definition your project will bring change into organization and any change will cause friction. On top of that you’re working against a benchmark – legacy system provided many years of reliable support. On top of that there may be people who have a high stake in maintaining the legacy system no matter what executives think.

Even if you’re an expert in your business domain it’s inevitable (and logical) that you’ll interact with an architect of the legacy system – who happens to have 20 years of experience with organization. Based on what the legacy system architect knows he doesn’t see the need for a paradigm shift that your solution will bring. What to do?

One approach is to involve the legacy architect with your project. The involvement can be kept at a high level; acknowledge the success of the retiring system and ask the legacy system architect to contribute to system requirements of the new system. A good question to ask: “What are the items on your [legacy system] wish list that could not be achieved due to hardware (e.g. mainframe) or software (e.g. COBOL) limitations?” Work with the legacy system architect to show how technology used for the new system will retain the essence of the retiring solution and allow for suggested improvements.

The key to your success is winning over the key stakeholders of the retiring system through diplomacy. Remember that “Diplomacy is the art of letting someone else have your way.”

Constantin K.
Firebrand Architect™
www.SoftwareArchitectures.com

Advice for apprentice software architects

2007-12-12T00:08:00.000-05:00

The software architecture discipline has matured to the point where the core tool bag for architecture analysis and design can be learned by any serious software engineer. But this doesn’t mean that architect’s experience is no longer an important attribute of architect’s character.

The best way to learn is by doing. To quote Lakota Indian saying: "Tell me, and I'll listen. Show me, and I'll understand. Involve me, and I'll learn." Apprentice architects must seek out opportunities to work on architecturally significant aspects of various projects. Diversity here means working on projects with different SDLCs, projects of different scope and size, and projects across different functional domains. Diverse experience – preferably across different organizations – will enable an apprentice architect make better decisions in the future as the repertoire of skills and knowledge grows.

Everybody wants an architect with 10 years of experience, but nobody wants an architect with 1 year of experience ten times.

Constantin K.
Firebrand Architect™
www.SoftwareArchitectures.com

Globalization and Software Architecture

2007-12-11T00:12:00.000-05:00

When I interview potential team members I always ask the question: “What is the impact of globalization on our company and on our clients?” This is not an easy question to answer and I’ve seen recent college grads and seasoned leaders alike cringe when they hear this.

The topic of the global economy is familiar to the IT folks. Many practicing architects are leveraging or at least familiar with the outsourcing software development models. But thinking beyond software architecture – what impact does globalization have on the business problem you’re trying to solve? Perhaps the problem you’re trying to solve is now nonexistent, or perhaps the complexity of the problem just increased by a factor of ten.

“What is the impact of globalization on software architecture?” This question I will try to answer in this blog in the near future.

With no clear answers this topic is a zero day problem for pessimists and a vibrant opportunity for optimists.

If you’re looking for a primer on the general topic of globalization I highly recommend reading "The World Is Flat" by Thomas Friedman.

Constantin K.
Firebrand Architect™
www.SoftwareArchitectures.com

Criteria For Failure

2007-12-06T23:37:00.000-05:00

Every project team asks themselves, implicitly or explicitly, what are our criteria for success? Depending on the range of the stakeholders involved you’ll get answers from the superficial (e.g. “users of all skill level can use software”) to the goal oriented (e.g. “identify the safest and most viable customers who need car insurance”). It’s easy to talk about success – especially non-quantifiable success.

The Firebrand Architect philosophy encourages you take a step further and pose a question: “What are our criteria for failure?” In other words – when we look back a year from now how would we know for sure we have failed to achieve our objective? Depending on your relationship with the group of the stakeholders you may have to be diplomatic as to how you pose the question.

Let’s work through an example. A project aims at providing insight into the inventory stored in many warehouses. The goal is to keep the inventory as low as possible while providing quick response to product demand. This project has a budget of $2,000,000 and will require a purchase of expensive COTS software ($500,000). A team of stakeholders will let the technical team decide which of the vendors to select, but know that a mature COTS software package has solved a similar problem in other organizations.

A year goes by, hardware has been purchased, COTS software installed and linked to a data warehouse, insight for a few categories of inventory can be obtained. Is this project a success or a failure?

One may say that since the software has been installed and connected to a data source in the production environment it’s a success. If that’s the only claim to fame, then this project is a failure. It doesn’t produce the insight that a business needs.

Using the same example as above, if a project produces some level of insight, but not all what was envisioned was it a failure or success? This is a harder question. If the paradigm and the model of operation through which the limited insight has been developed can be naturally expanded to gain insight in all envisioned categories, then the project is a success despite not delivering everything what was planned. If the paradigm doesn’t scale to cover additional level of insight, then the project is a failure.

Knowing the definition of success is important. Knowing the definition of failure is paramount.

Constantin K.
Firebrand Architect™
www.SoftwareArchitectures.com

Conceptual Integrity

2007-12-04T22:06:00.000-05:00

It’s a well known fact that deciding what exactly to build is the hardest part of software development. So how does one deal with complexity and uncertainly? Sanity is retained and complexity managed by maintaining conceptual integrity in your solution. This goes beyond the conceptual integrity of the architecture, but the conceptual integrity of a solution.

As an architect who will start working from a set of initial requirements (and later work with the requirements management team to refine requirements) you need to understand why a business problem is being presented in a given way and why it’s being solved in a given way. The business problem and the conceptual solution need to be rational and need make sense as a whole. It’s not necessary, moreover – counterproductive, to have details at this level, but having a conceptual integrity of a solution before investing heavily into architecture design and analysis is paramount.

Constantin K.
Firebrand Architect™
www.SoftwareArchitectures.com

Evaluating SOA using ATAM

2007-10-22T17:47:00.000-04:00

This report, released by the SEI in September of 2007, is a very good example of applying the ATAM to evaluating an architectural style, such as SOA. You can find the report here.

The Abstract
"The emergence of service-oriented architecture (SOA) as an approach for integrating applications that expose services presents many new challenges to organizations resulting in significant risks to their business. Particularly important among those risks are failures to effectively address quality attribute requirements such as performance, availability, security, and modifiability. Because the risk and impact of SOA is distributed and pervasive across applications, it is critical to perform an architecture evaluation early in the software life cycle. This report contains technical information about SOA design considerations and tradeoffs that can help the architecture evaluator to identify and mitigate risks in a timely and effective manner. The report provides an overview of SOA, outlines key architecture approaches and their effect on quality attributes, establishes an organized collection of design-related questions that an architecture evaluator may use to analyze the ability of the architecture to meet quality requirements, and provides a brief sample evaluation."

Firebrand on duty: Constantin K.
www.softwarearchitectures.com

Neglected Aspects of Software Architecture

2007-09-24T23:13:00.000-04:00

Todd Kaiser, a Chief Architect of Government Systems at Raytheon Intelligence & Information Systems, delivered an outstanding presentation at the 2007 SATURN workshop. The absolute beauty of the presentation is simplicity with which he delivered a very important message: some software architects ignore non-technical aspects of software architecture that results in “collateral damage.” In addition to concentrating on technical pillars of a solution: data, structure, and behavior, an architect must also actively weigh managerial, financial, and contractual aspects of software architecture. Your personal architecture world may be different, but Todd Kaiser’s presentation succinctly delivers the message that applies to most architects: architecture is more than just technology.

SATURN 2007 presentation on Neglected Aspects of Software Architecture.

Firebrand on duty: Constantin K.
www.SoftwareArchitectures.com

Architecture is in expressly delightful

2007-09-20T16:48:00.000-04:00

"Architecture is expressly delightful, and of the greatest convenience to mankind in all respects, both public and private; and in dignity not inferior to the most excellent. …. Him I shall call an architect who, by a sure and wonderful art and method, is able, both with thought and invention, to devise and, with execution, to complete all those works which, by means of the movement of greatest weights and the conjunction and amassment of bodies, can, with the greatest beauty, be adapted to the uses of mankind: and to be able to do this, he must have a thorough insight into the noblest and most curious sciences." Leon Battista Alberti (1450)

Firebrand on duty: Constantin K.
www.SoftwareArchitectures.com