Firebrand Architect®

soft skills

2009-07-07T16:38:00.003-04:00

Great blog post on recognizing the importance of the ever changing soft skills with respect to delivering technical solutions. Link.

festina lente

2009-06-12T21:40:00.003-04:00

"I don't think much of a man who is not wiser today than he was yesterday. " ~Abraham Lincoln

Learning is essential in every discipline and architects often carry a double duty of learning both the technical angle and the business angle. But there is another angle that you, as an architect, must learn, and that's the human angle.

In a recent three day working session with a rapidly developing project I was following the well defined path of working with the clients through the core business processes, defining technical pieces of a potential solution, etc. Early on I was fortunate to realize that despite coarse grained requirements provided by the team there wasn't much substance (conceptual integrity) in what was said by the stakeholders.

That was a clue to take extra time to understand just how much and how well the stakeholders understand the business problem at hand. By listening and learning quickly from them I re-scoped the day's discussion and concentrated solely on a short term solution capabilities. This provided confidence to the stakeholders that they understand a solution using their limited knowledge of technology and provided a base for future long term solution discussion.

Summary: always be ready to re-scope the discussion to meet the immediate needs of your stakeholder even if the previously set agenda promised to cover the world.

Constantin K.
Firebrand Architect®
SoftwareArchitectures.com
FirebrandArchitect.com

patterns & practices - Application Architecture Guide 2.0

2009-03-23T16:59:00.001-04:00

"This guide provides design-level guidance for the architecture and design of applications built on the .NET Framework. It focuses on the most common types of applications, partitioning application functionality into layers, components, and services, and walks through their key design characteristics.This guide is a collaborative effort between patterns & practices, product teams, and industry experts."

http://www.codeplex.com/AppArchGuide

It's a useful guide, but use with caution. At times the authors confuse the perspective. For example a "tier" is used interchangeably with a "layer." This is not correct since a tier is usually defined to exist in a run time perspective and a layer in a static perspective. All in all a very useful composition.

Constantin K.
Firebrand Architect®
SoftwareArchitectures.com
FirebrandArchitect.com

Complexity in Software Architecture and a new architect role

2009-03-22T16:13:00.001-04:00

Things are just getting worse for software architects. Relative stability of business models and computing paradigms of the 2000's has vanished. Making the right early design decisions has become very difficult. Keeping up with technical and operating environment complexity has become nearly impossible.

Humans deal with complexity through abstraction. With rapid growth of complexity in the software architecture domain (both business and technical perspectives) we're now seeing divergence of software architect roles. It's not possible to be a great security architect, a great performance architect, and a great general software architect at the same time. Recently architects have been specializing, often not by choice, to fit the business domains and their operating environments.

The important point is that a new breed of architect role needs to be officially recognized. It may be called a composer, orchestrator, manager, or a solution architect. In this role an architect would only be responsible for creating and maintaining the conceptual integrity of a solution. The conceptual integrity then needs to be maintained and managed in light of changing environment (new constraints, funding, requirements, policy, staff). This architect role would be responsible for making the right timely decisions as to when to bring in appropriate experts. Some may argue that this role exists now and it's the role of a software architect, but it's not possible for a single person to orchestrate the activities of other specialists and be responsible for technical structure of the whole solution.

Over the past few years ( 2006 - 2009) a new trend has developed where more and more architects specialize in a specific area of quality attributes (e.g. security, performance, usability) and relive themselves of duty of the end-to-end solution ownership. There is no question that specialization is necessary to gain the appropriate level of technical depth to be effective, but who is left to be responsible for the conceptual integrity of a solution? Often this role is filled by someone who doesn't understand how specialists work together and how they must be integrated together. Yet this is a very important role, because in order for specialists to be effective their input must be appropriately timed. For example, when was the last time security was effectively retrofitted into an already existing solution? An orchestrating architect needs to recognize the need for a security specialist and then figure out when to incorporate that expertise into the project.

This orchestrator role doesn't explicitly exists because organizations expect professionals to be either technical software architects (sometimes listed as senior software engineers in job advertisements) or project managers. The recognition for something in between doesn't exist.

Successful projects have someone who maintains the end-to-end perspective. It's a challenging role as a person doing this is likely doing this along a set of other major responsibilities.

As the complexity of our computational environments and the complexity of business solutions has expanded we need realize that in order for software architecture specialists to be effective their work needs to be thoughtfully orchestrated by someone who has time, resources, and authority to create and maintain the end-to-end conceptual integrity of a software solution.

Constantin K.
Firebrand Architect®
SoftwareArchitectures.com
FirebrandArchitect.com

Fifth SEI Architecture Technology User Network Conference (SATURN 2009)

2009-03-18T22:31:00.003-04:00

I "subscribe" to the general principles of the Software Engineering Institute's (SEI) software architecture paradigm. I apply various aspects of the approach in my day to day activities. If you're a fan of the SEI's work on software architecture you should consider going to their annual conference (May 4 - 7, 2009) to mingle with likeminded colleauges. Early bird registration is through March 31st. A 10% off coupon may be available if you're interested.

Link to the conference site.

Constantin K.
Firebrand Architect®
SoftwareArchitectures.com

Analysis paralysis

2009-03-16T21:04:00.001-04:00

Analysis paralysis is a common problem in the software requirements domain. Engineers or requirements analysts become overwhelmed with amount of information and get bogged down in details.

Software architects face a similar problem. If an architects seeks perfection or the best solution for a given problem he or she may get bogged down in the details of various design alternatives. A more effective approach is to invest time in understanding the key architectural drivers - the requirements that have a profound effect on architecture (i.e. critical functional requirements, quality attributes, and constraints). By quantifying your requirements (e.g. by using quality attribute scenarios) an architect will be able guide your decision making process through various design alternatives.

As Fred Brooks said - getting the conceptual integrity right is the most difficult, but the most important part of your job. To help you with this process you should use an iterative approach to developing architecture and participate early and vigorously in the requirements elicitation and analysis phase.

Let the properly stated requirements shape your architecture and let the architecture shape your requirements.

Constantin K.
Firebrand Architect®
SoftwareArchitectures.com

The role of organizational politics in Software Engineering and Software Architecture design

2009-03-15T16:58:00.001-04:00

This is a very important topic I've been examining for a number of years. While my Ph.D. work on "the cost of organizational politics on software engineering" is many years away it's important to raise the awareness of this subject matter.

The topic of organizational politics is not new. The concept surfaced in 1958 and in early 1980's the topic was actively studied and analyzed. There is no definitive guidance since it's a challenging topic to study; after all this is about the behavior of people. There are many factors that shape the game of politics: individual values and ethics, organization's structure and the way of life (e.g. "cooking books"), environmental conditions (e.g. market stress), and performance reward criteria (e.g. measuring and rewarding the wrong results). What's clear from research is that there is a distinction between an actual political behavior and a perception of a political behavior. For a software architect it's important to recognize and manage both.

Design choices in software architecture are often based on experience and human factors, but architects often don't recognize this. It's natural since most software architects came from the trenches of software development where programming activities are closer to the actual implementation and hence more structured.

Some questions to consider:
- Does your organization openly recognize design constraints? E.g. organization has made a commitment to J2EE platform for solutions of type X.
- Is the effort of analyzing design alternatives, if exists, seriously considered when a design approach is selected?
- Are you aware how you personally avoid, reduce, or promote organizational politics? Not all politics are detrimental. The political game can be played to promote the goodness of software architecture design and implementation process.

It's good to admit that politics play a role in the design process. Actually it's healthy to admit so as it shows maturity of an organization or a team / person.

Remember that you as an architect make conscious and unconscious decisions in your day to day activities that may be perceived by others as political decisions. To protect yourself from unintentional consequences be sure that your personal priorities do not become your team's agenda, else the team chemistry is going to change and you're not going to like the result.

Constantin K.
Firebrand Architect®
SoftwareArchitectures.com

Insights from vendor panel on Cloud Computing (FOSE 2009)

2009-03-14T15:18:00.005-04:00

The leading providers of Cloud Computing services (IBM, Microsoft, Google, and Amazon ) gathered for a panel discussion at FOSE 2009 organized by Booz Allen Hamilton.

Observations:
- Standards have matured significantly over the past few years for both Software as a Service and Infrastructure as a Service.
- Significant gains have been made with respect to interoperability, but until vendors develop a usable way to collaborate adoption will be difficult.
- Trust will make or break clouds. Security is still a big issue - IPv6 will help.
- Private clouds are likely to come first before commercial clouds become widely used.
- A cloud provides substantial benefits when economy of scale is reached.
- Any organization considering cloud computing needs to develop and understand its total cost of ownership (TCO). Cost standards are not mature.
- Cloud Computing is not SOA.
- Cloud Computing maturity level models are being developed (Booz Allen).
- Demand for Cloud Computing has been established - there is a substantial market for the services.

Cloud Computing is becoming a viable option for mainstream software solutions. What does this mean for a software architect? More design options, new design patterns, and greater solution flexibility. Cloud Computing will require substantial investment in education and experimentation in order to understand its limits and applicability to your business solutions.

Constantin K.
Firebrand Architect®
SoftwareArchitectures.com

Cloud Computing Wargames at FOSE 2009

2009-03-13T16:00:00.002-04:00

Booz Allen Hamilton held Cloud Computing Wargaming sessions at FOSE 2009 (March 10 - 12th 2009). This wargame simulates the thinking process and the choices IT decision makers have to make in real world as they develop organization's capabilities to meet business or mission challenges. The goal of the exercise is to get the players thinking about the tradeoffs between different computing resources, associated costs, risks, and resulting benefits.

Cloud Computing is not a new concept, but with rapid progress of standards and maturity of technologies "on demand" computing has become a viable option for many organizations.

During the 90 minute session a table competes against six other tables. The goal of the game is to collect Mission Value Points (MVPs). A team obtains MVPs upon successful completion of tasks. To complete a task a team must build a set of capabilities required to support a task. A capability can be built in "Traditional IT", "Hybrid Cloud", or "Commercial Cloud". Over the course of the game a team builds up a portfolio of tasks it has to support. Upon completion of each turn if a given task has been successfully supported with existing capabilities, then a team gets an established number of MVPs for that task.

Players quick realize that in "Traditional IT" computing environment the invested resources cannot be rapidly re-allocated to meet challenges of new tasks. Moreover additional human resources are necessary to support "Traditional IT." Cloud Computing is not a cheap option and there is a resource barrier if a team chose to build their own cloud. Similarly with the "Commercial Cloud" a team would loose invested money and have less control of the services available through that offering.

Watch Booz Allen Principal Rod Fontecilla comment on the essence of the game. Lessons learned from a croupier's perspective in a future post.
<a href="http://video.msn.com/?mkt=en-US&playlist=videoByUuids:uuids:25029772-6d0f-4ce5-809e-280bd49f9db5&showPlaylist=true&from=msnvideo" target="_new" title="War Games">Video: War Games</a>

Constantin K.
Firebrand Architect®
SoftwareArchitectures.com

How Business Goals Drive Architectural Design

2009-02-17T22:45:00.002-05:00

How do quality attributes affect the architectural design of a software solution? If we only cared about the functional requirements of a software solution, then any architecture and any implementation would suffice. Further, how business goals drive architectural design?

The topic of translating business goals into architectural drivers merits a separate post, however this article from the August 2007 edition of the Computer magazine (IEEE Computer Society) eloquently demonstrates how the architecture of a software solution changes as business goals are refined into quality attribute scenarios. Application of architectural patterns and refining tactics significantly alter the architecture of a software solution.

Constantin K.
Firebrand Architect®
SoftwareArchitectures.com

Architecting Software Intensive Systems: A Practitioners Guide

2009-02-10T18:22:00.000-05:00

In summary of chapter 5, The Work of an Architect, the author notes that "… this is not intended to be a definitive statement on how to architect. Architecture design is guided by the intuition and judgment of the architect. The purpose here is to provide principles and guidance for how tot think about decomposing a system, what to consider when decomposing the system, and how to capture key design choice and rationale." This chapter alone is worth the price of the book, Architecting Software Intensive Systems: A Practitioners Guide, as it proves invaluable guidance in a clear and concise manner.

Make space on your bookshelf that's located closest to your desk. Buy this book. Use this book.

Few practitioners have the level of depth and breadth necessary to eloquently capture and explain the practical aspects of the software architecture discipline. The author, Anthony J. Lattanze, explains the critical need for separating perspectives (static, dynamic, physical), explains architectural drivers, and provides guidance for architectural design. The rest of the book covers the Architecture Centric Design Method - a practical approach that you can use from concept initiation to solution sunset.

Constantin K.
Firebrand Architect®
SoftwareArchitectures.com

The process of learning the principles of software architecture

2009-02-09T21:15:00.001-05:00

This is my second year serving as the distance education instructor for Carnegie Mellon's Principles of Software Architecture course. The distance education course is aimed at working professionals and has the SEI Software Architecture paradigm as a backbone. The course is based on the same material taught in the Masters of Software Engineering program at the Carnegie Mellon by David Garlan and Anthony J. Lattanze.

I spend time interacting with students through conference calls, class bulletin board, emails, and assignment grading. It's very interesting to see how professional software engineers and architects with many years of experience learn new ways of thinking and reasoning about software architecture. This experience offers me a unique perspective to see how people learn about a disciplined way of thinking about the art and science of software architecture.

Experienced software engineering professionals who design and build non-trivial software systems as part of their day-to-day responsibilities have no major problems adopting to the SEI Software Architecture paradigm and other software architecture topics taught in the course. But what about those with little design experience? On the topic of architectural patterns, architectural styles, design patterns, and design in general the biggest problem is judging the scope and applicability of a given pattern or a style. When asked to indentify the most appropriate architectural style for a given system implementation students become confused. Would SOA be an appropriate style? Or may be the MVC pattern? But wait, a software system may be a heterogeneous composition of multiple patterns and styles. So how can there be a single overarching pattern? In other words the students with less experience appeared to have trouble focusing the lens (of the "right" answer) on the problem.

Does this mean time and experience is the only way to become a better architect? Absolutely not. After taking this course the students who didn't have an ideal level of experience will look at every single software architecture challenge from a different perspective. They will question their decision and decisions of others. They will demand to understand why decisions are made one way or another. As they learn and experience different design patterns and architectural styles they will see get the "aha!" of the questions asked in the weekly homework reading questions.

If you're just beginning to learn about software architecture please understand that it's a journey and not an event. While the Software Architecture course from Carnegie Mellon's School of Computer Science can make you think about software architecture in a disciplined way it will not make you an expert architect. Learn and read everything you can from diverse sources since it's still a maturing discipline. Take everything that you learn with a grain salt. Ask "why?" on major decisions and think like a firebrand™.

Constantin K.
Firebrand Architect®
SoftwareArchitectures.com

Simple Architectures for Complex Enterprises

2009-01-31T18:16:00.002-05:00

Measuring complexity of business processes and software solutions that support them is a difficult task. Roger Sessions in his Simple Architectures for Complex Enterprises book provides an excellent math (logic) based approach for examining Enterprise Architecture complexity without getting into formal methods. The philosophy behind the approach is superb and refreshing. The chapter on technology approaches will be obsolete soon, but chapters 1 - 5 will be applicable for years to come.

Constantin K.
Firebrand Architect®
SoftwareArchitectures.com

A new era of responsibility

2009-01-20T23:48:00.002-05:00

As president Barack Obama was delivering his inaugural address on January 20th 2009 I was taking notes on how his theme of a "new era of responsibility" will affect my clients and my colleagues. Software architects have a tremendous power to make or break a system. With such power should come a great level of responsibility. But how often do you hear architects taking full responsibility for the design of a software solution? How often do you hear architects clearly justify why a certain design was chosen among an array of alternatives and how specific tactics will address domain specific business needs? Just check any software licensing agreement: [company] makes no warranties, express or implied ...

Has the time come for responsible software architecture and responsible software engineering? As a software architect how will you handle a new era of responsibility?

Constantin K.
Firebrand Architect®
SoftwareArchitectures.com

Dealing with the bus problem

2009-01-01T15:26:00.003-05:00

When a "bus problem" becomes a reality it's critical to address the human needs first. This post does not provide guidance on how to deal with loss, but if you're in a leadership position you need to know how to appropriately respond or where to go for help.

Ultimately if you hold a key position in your organization (e.g. reputable architect or a trusted advisor) you may be called upon to help right away. Your first order of business should be to get the software solution up and running by all means necessary. Be prepared to look at the source code, log files, incomplete documentation, conduct interviews with frustrated users. You will be looked upon as a savior whether you're ready or not, so you must be prepared to act like a Swiss army knife. In this situation the pressure is high and failure is not an option.

Here are the guidelines to help you think when under pressure:
- Create a plan of action. Write down everything you think you need to do. Use this list as a start.
- Understand the business need and function of the solution. Bus problems usually don't occur on properly managed large scale solutions with a clear mission. There is a very good chance the solution affected by a bus problem supports informal business processes that you don't know about.
- Learn everything you can about the solution. Seek people who may have worked on the previous version, seek hard copies of presentations and documentation if soft copies are not available.
- Think about the technical aspects of the solution. Based on the technologies used and your experience with the application (if any) you may make some assumptions about architectural patterns used. But be careful assuming that the patterns are being used correctly. An opportunistic solution is very likely to have improperly used (or misused) architectural patterns or simply poor implementation. Hope for the best, but expect spaghetti code.
- If you're not proficient with the technology used find a smart software engineer to work with you side-by-side. At this stage this person will be your partner - not a subordinate.
- Be aware of the political landscape. If the solution in question was developed and managed by a different organization devise a strategy with your senior leadership to diplomatically address this issue. The organization owning a failed solution may be well aware that they were irresponsible by letting the affected solution operate in such manner. Think about an exit strategy for the responsible organization to gracefully "save face."
- Write a short draft proposal (1 or 2 pages) of how the broken solution should evolve into a mature environment so that it can be supported by your organization's IT. You will have ideas as soon as you start looking at this problem so you may as well write them down from the perspective of your organization's computing infrastructure.

This is not a complete list, but it will help you handle the knee jerk reaction you may be expected to perform. Act quickly, but systematically. Understand the business value of the solution that's hidden from the official view, get the solution up and running immediately by using whatever it takes approach, rapidly evaluate near term needs, and think about the long term needs.

You may want to bookmark this post so that you can find it quickly in the time of need.

Constantin K.
Firebrand Architect®
SoftwareArchitectures.com

The Bus Problem

2008-12-28T13:34:00.001-05:00

Software engineering practitioners joke about this all the time, and it’s a classic management problem that is deeply rooted in the software engineering folklore. There exists a person who singlehandedly built software program that supports some important business function (in production environment of course). Everyone knows that there is virtually no documentation, no one else knows the code, there is no source control, and this is the only person who can maintain the program. And if that person gets hit by a bus and dies there will major issues, but it’s better not to think about it.

Even in the organizations that have mature software engineering processes the bus problem persists. This is because all organizations have opportunistic projects (programs) developed by a person or two. These programs, usually developed as unofficial side projects, support informal business processes that provide significant benefit to the end users at little cost. These opportunistic projects are usually developed in a haphazard way, because there is no spare time and they are targeting a very specific audience. Examples of this type of program may be a custom authentication mechanism that is small enough to be developed and maintained by a single person. Such solution may have been intended to be used for just a single software solution, but over time it became an important component of multiple software intensive solutions, or this program became the vehicle for supporting a core official business process.

My colleague responsible for a project that fits the description above has been hit by a “bus”.

Future posts will provide lessons learned from the experience written from an architect’s point of view:
• Dealing with the bus problem
• Anticipating the bus problem
• Preventing the bus problem

Constantin K.
Firebrand Architect®
SoftwareArchitectures.com

Taking care of your people

2008-12-16T22:54:00.002-05:00

This post is about taking care of your colleagues and employees. With holidays rapidly approaching many people scramble to say thank you and congratulate their subordinates and colleagues. This behavior often leads to awkward moments and superficial exchanges of gratitude. Don’t do it.

If you haven’t been taking care of your people through the year consider changing your behavior. By saying “taking care” I don’t mean buying expensive gifts or giving superficial awards. What I mean is enabling your colleagues and employees to support you in the most productive way possible while operating in a professional environment. In life it’s the small things that leave a lasting impression that make people happy.

Let’s say your new team members all have standard company issued laptops with 1 GB or memory. The software tools they use to model architecture and conduct analysis functions result in thrashing and frustrating usability experience. Closing Outlook and IDE makes the modeling software run fast, but that’s not the solution. Your first action is to immediately buy an additional 2 GB of RAM for each person and have it shipped express mail.

Surprise your colleagues by baking cookies from scratch. Not bringing left over batch or buying a package, but purposefully making something for the team. This element of surprise and pleasant goodness clashes with the ordinary daily routine. This is a great way to say thank you in a very small way.

Finally, create and maintain a professional working environment. This may be difficult if the rest of the organization is not ethical or the senior management doesn’t appear to care. It’s important for you, as a leader, to create a sense of belonging. You must consistently address any unprofessional behavior within your team so that your employees can concentrate on delivering the best work rather than dealing with non-work related distractions.

Enabling your team to support you with proper tools in a professional work environment through the year will make you more productive and holiday times less awkward.

Constantin K.
Firebrand Architect®
SoftwareArchitectures.com

Architecture evaluation attititude

2008-10-27T22:59:00.003-04:00

When faced with a task of architectural evaluation of an existing system a software architect may make an assumption that something must be wrong with the architecture. Of course if someone asks you to perform such task your first question is to understand what is implied by “evaluating the software architecture of an existing system.” Before any work of technical nature commences the business purpose of the evaluation task needs to be established.

The goal of an evaluation is not to determine what is right or what is wrong. The goal of an evaluation is to gain an understanding of how a system is constructed. It’s always healthy to be skeptical – we advocate this strongly as it’s the mantra of the Firebrand Architect® blog – but also give a “benefit of the doubt” and try to understand why a solution was architected one way or another. Remember that the system was designed and implemented under constraints that may no longer be true today.

As a public service announcement, please do your colleagues a favor and methodically document your solutions, and most importantly the thinking process behind your decisions. If someone has to conduct architectural reconstruction on a system you've architected (instead of architectural evaluation based on existing documentation), then you've done this discipline a disfavor. Thank you in advance for being considerate.

Constantin K.
Firebrand Architect®
SoftwareArchitectures.com

Architect-as-contractor model in building architecture

2008-10-14T22:22:00.001-04:00

In the October 10th 2008 Wall Street Journal article, House Designers Don Hard Hats, the author describes the architect-as-contractor model called design-build. This approach is the unquestionable standard in the software engineering world. This article vividly demonstrates some well known parallels between building and software architecture.

Some points to note. The design-build model works only when the design documents are extremely detailed - down to the last screw or caulking decision. There are upward of thirty different architectural views for a $5M project. And of course an architect is playing the role of a developer by participating in the day-to-day building activities.

The article offers interesting reaction to this approach from former customers. Since there has been some isolated discussions in the software architecture community of the separation of high level design from implementation it’s worth a look.

Constantin K.
Firebrand Architect®
SoftwareArchitectures.com

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.002-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