Firebrand Architect®

Re-post: "Importance of Well Designed Software"

2011-12-28T16:21:00.000-05:00

Great blog post by Agile Journeyman about Martin Fowler's Design Stamina Hypothesis & the Technical Debt Quadrant.

Constantin Kostenko
Firebrand Architect®

Microsoft Application Architecture Guide, 2nd Edition

2011-10-21T21:25:00.000-04:00

This book, Microsoft Application Architecture Guide, 2nd Edition, has a few sharp edges, but it's a good place to start with the intention to continue learning about the discipline from other sources.

Teaching is learning

2011-07-10T23:10:00.000-04:00

Seeing people learn is exciting. I really enjoy my part-time gig working as a Distance Education Instructor supporting the Software Architecture eLearning course at the Carnegie Mellon University. It’s exciting to see students, who are many years into their professional careers, learning about a disciplined way of thinking about software architecture. These students are not there because they have to be there, they are there because they (and their employers) see value in learning and applying a disciplined approach to building software intensive systems.

During the semester long three phase project it’s interesting to see students get to the “Aha!” moment when they try to reason about system decomposition and fail because the quality attributes they specified were not defined in a precise manner. Since quality attributes define the behavioral properties of the system they (along with business and technical constraints) impact the selection of architectural patterns and tactics. It’s the students’ desire to go back and re-work a previous phase of the project that shows they understand their mistakes and want to learn from them.

What helps students learn is detailed feedback on their project and their responses to the lecture and reading material. For students this course is an opportunity to learn how to think about analyzing software architecture now and in future. It’s a place to learn, make mistakes, and get effective feedback. And for me it’s an opportunity to reflect on my professional experiences and learn about myself by teaching the software architecture discipline to others.

Constantin Kostenko
Firebrand Architect®

CASCON 20th Anniversary - First Decade High Impact Papers

2011-04-15T11:21:00.003-04:00

From the CASCON site: "Conference of the Center for Advanced Studies on Collaborative Research [published] First Decade High Impact Papers as part of the 20th anniversary past papers presented at CASCON which had delivered high industrial and academic impact are being recognized. Headed by Hausi Müller, the specially created CASCON First Decade High Impact Papers (FD-HIP) Selection Committee selected 14 papers from the 425 papers published during the first decade as winners. The selected papers are featured in a special CASCON proceedings volume. As well, the authors celebrated through the First Decade High Impact Papers will be recognized during the Monday, November 1st keynote at 1:00 p.m, and will also be on hand to attendees during the Technology Showcase Reception on Monday, November 1st to discuss their influential works."

Link to the listing of papers.

Constantin Kostenko
Firebrand Architect®

2011 Outstanding Research Award from ACM SIGSOFT

2011-04-05T10:03:00.001-04:00

David Garlan and Mary Shaw win the 2011 Outstanding Research Award from ACM SIGSOFT.

"This award is presented to an individual who has made significant and lasting research contributions to the theory or practice of software engineering."

Constantin Kostenko
Firebrand Architect®

Highly anticipated & somewhat overdue

2010-10-18T20:34:00.002-04:00

This book needs no introduction to serious software architects ... Documenting Software Architectures: Views and Beyond (2nd Edition) is finally here.

“This new edition is brighter, shinier, more complete, more pragmatic, more focused than the previous one, and I wouldn’t have thought it possible to improve on the original. As the field of software architecture has grown over these past decades, there is much more to be said, much more that we know, and much more that we can reflect upon of what’s worked and what hasn’t—and the authors here do all that, and more.” —From the Foreword by Grady Booch

Constantin Kostenko
Firebrand Architect®
SoftwareArchitectures.com
FirebrandArchitect.com

Domain specific patterns

2010-05-22T18:07:00.002-04:00

One way to become a recognized expert in your line of work is to become versed in your organization's domain specific design patterns. You will gain an exponential level of recognition if you contribute to codifying these patterns. Be proactive in documenting and sharing design patterns specific to your problem (business) domain. Few organizations invest resources into codifying the non-standard design patterns even though they are implemented often (hence the name). If you're the one recognizing and documenting domain specific design patterns you'll become a recognized expert.

By now many organizations have internal wiki-like collaboration tools. That’s the best place for you to start documenting these domain specific design patterns. Use that collaboration space to involve others. To be effective select an existing (or create your own) framework for describing design patterns. Many frameworks and approaches exit, pick one that works and modify as you go along. Just remember that design patterns apply to different level of design granularity.

Why is this important? Reuse at architectural level. Further, domain patterns may lead to reference architectures. This will help you and your organization reuse design concepts. Reference architecture (specific to your domain) may then result in an implementation framework (again, specific to your domain) that may contribute to development of product lines.

Constantin Kostenko
Firebrand Architect®
SoftwareArchitectures.com
FirebrandArchitect.com

Have a clear exit strategy

2010-05-22T17:41:00.001-04:00

When are you done architecting? How long should the architecting phase take? These are very common questions that often don’t have a common answer. Your answer depends on what you’re trying to achieve and your operating environment.

The first step is to understand your environment and your constraints. Both technical and organizational. As Fred Brooks said in his new book The Design Of Design: “constraints are friends.” Constraints bound you and the scope of your work. You must still understand and feel the difference between a real constraint and a perceived constraint (often political) and a requirement.

The second step is to define your exit strategy. This must and can be defined shortly after you understand the general nature of the problem and your role in defining a solution. This requires understanding the role of downstream designers and implementers (even if you may be playing those roles as well). Without clearly defining the success (and failure) criteria before you invest your time your work is never going to be good enough. It’s a given fact that your success criteria and your exit strategy may change through the design process, but having a baseline will make it easier for you to handle changes in the future. But most importantly you’ll know when you’re done.

Constantin Kostenko
Firebrand Architect®
SoftwareArchitectures.com
FirebrandArchitect.com

The most costly defects are design defects

2010-05-20T17:29:00.000-04:00

In software the most costly defects are design defects. If you play the role (or carry the title) of a software architect be sure that you’re explicitly architecting your systems versus letting the designs emerge. The design shall emerge whether you want it or not, but you may not like the results. Further, be sure you understand and document your design decisions in the context when they were made. Undisciplined system design is irresponsible and is only appropriate for experimental solutions and throw away prototypes (that are guaranteed to be thrown away).

Constantin Kostenko
Firebrand Architect®
SoftwareArchitectures.com
FirebrandArchitect.com

What's this pattern's level of abstraction? It depends.

2010-05-12T15:58:00.001-04:00

In building architecture we often easily recognize when one pattern fits into another pattern. Perhaps this is because physical things are easier for us to touch, feel, see, and sense. For example, in A Pattern Language book, Christopher Alexander clearly shows how building and city planning patterns fit with each other. Take the Activity Pockets pattern as an example. The essence of this pattern captures the fact that in order for an open public space to be vibrant and lively it needs to have a set of activity pockets at its edges. As the number of activity pockets expand the whole open space becomes lively. So if an urban designer’s design goal is to create a lively public space he or she may choose to apply this pattern. This pattern (#124) “helps complete the edge of all these larger patterns … Promenade (#31), Small Public Squares (#61), Pedestrian Street (#100), Building Thoroughfare (#101).” At the same time this pattern is further refined by the following downstream patterns: Arcades (#119), Trellised Walk (#174), Sitting Wall (#243), just to name a few. It’s easy to see the granularity level of the Activity Pockets pattern in the context of a city and a building.

The above mentioned pattern makes sense, especially when combined with a topology map, but what about software patterns?

In the software architecture world the granularity of a given pattern is not always obvious. In case of well known patterns, such as client server or its derivative N-tier, everyone knows that they represent a systemic level of abstraction. But less known patterns may confuse architects, especially if some patterns is widely recognized as systemic, but is encapsulated inside of some other systemic pattern. For example, a 3-tier overarching architecture may have a data repository pattern (also known to sit at a systemic level of abstraction) hidden at the next level of decomposition in the data tier.

The key to dealing with potential confusion is to clearly explain (and document) patterns used and why. Further, maintaining a proper perspective (i.e. dynamic, static, or physical), as mentioned in the previous post, is critical when showing how one patterns supports another pattern.

Constantin Kostenko
Firebrand Architect®
SoftwareArchitectures.com
FirebrandArchitect.com

Don't mix up architectural perspectives

2010-05-02T15:00:00.005-04:00

No real world system consists of a single [software] architecture pattern. Most systems are a combination of multiple patterns (a.k.a. styles) that together make up a solution. A common mistake that some architects make, when documenting software architecture, is mismatching different perspectives. For example, showing a layers pattern coupled with a process threads pattern within the same perspective makes no sense since layers is a static perspective and threads are associated with a dynamic perspective. It’s like mixing apples and oranges. In some cases it’s beneficial to show how a static (modules) perspective maps to a dynamic (run time) perspective, but such composition can occur when you already have two other perspectives.

Constantin Kostenko
Firebrand Architect®
SoftwareArchitectures.com
FirebrandArchitect.com

In software engineering we’ll never reach a plateau

2010-03-26T07:43:00.003-04:00

On March 12th and 13th I attended the 20th anniversary of the Masters of Software Engineering Program at Carnegie Mellon. It was great to reconnect with alumni and learn about the continuing progress of the professional software engineering program.

The Saturday program included a talk by Bill Scherlis, a professor of Computer Science at Carnegie Mellon University and Director of the Institute for Software Research, who talked about the current and future state of the software engineering practice.

Key points:

- There is constant struggle for order & predictability, but the more we struggle the less we succeed.

- Productivity paradox – economists still cannot clearly measure impact of software / IT.

- Constant innovation is the mantra of the software world – we’ll never reach a plateau. As soon as we reach a "stable" state we'll have various pressures requiring us to innovate.

- Disruptions happen all the time. Change is constant.

- Conway’s law is still the law.

- More’s law is still the law.

- The end users also have the same burden of keeping on top of innovation as they still need to keep making good choices.

The general ideas of the talk can be found in this article.

Constantin Kostenko
Firebrand Architect®
SoftwareArchitectures.com
FirebrandArchitect.com

The Design of Design: Essays from a Computer Scientist

2010-03-20T20:30:00.002-04:00

Fred Brooks has always been ahead of his time; about 20 years ahead to be precise. His new book, The Design of Design: Essays from a Computer Scientist, goes on sale soon. Pre-order it now.
It will be a timeless classic. If you need to ask why such a bold statement then you need to read The Mythical Man-Month: Essays on Software Engineering.

Constantin Kostenko
Firebrand Architect®
SoftwareArchitectures.com
FirebrandArchitect.com

Sun Tzu

2010-01-18T15:37:00.001-05:00

“Strategy without tactics is the slowest route to victory. Tactics without strategy is the noise before defeat.” -- SUN TZU

Constantin Kostenko
Firebrand Architect®
SoftwareArchitectures.com
FirebrandArchitect.com

Follow the money

2010-01-17T22:28:00.002-05:00

An idea or a software project is only as strong as availability of funding. In times of crisis the source of funding and executive sponsorship may change quickly. Business owners and software architects must plan for this; architects must persistently take this fact into account when they design and when code is written.

At times of instability it's paramount to show continuous progress. From design perspective decoupling, as a quality attribute, becomes very important. If a source of funding or ownership changes and a core component (that delivers desired business functionality) needs to shift from project A to project B, it must be done quickly and successfully. A highly modular design will allow uprooting a logical segment of a system and reviving it as part of another project. In these situations strictly adhering to solution architecture during implementation is imperative, because when funding is cut you have little time to wrap things up. Developers must understand the importance of adhering to architecture and rationale for this design. Code reviews must be conducted to police architecture implementation. Everyone on the team, from testers to developers, must understand that in times of crisis flexibility becomes a core design need.

Understand the project funding flow in your organization, follow the money, and design for flexibility in the times of change.

Constantin Kostenko
Firebrand Architect®
SoftwareArchitectures.com
FirebrandArchitect.com

Anyone can takeoff, can anyone land?

2009-12-20T17:27:00.002-05:00

Oh prototypes. We love them, clients love them, users love them. They help with requirements and sometimes help us answer architecturally significant questions.

But early success creates a false sense of security. A successful prototype that a senior manager or a customer loves cannot always be operationalized in a matter of days or weeks. If fundamental quality attributes of software have not been thought through (e.g. security, scalability, performance, etc.) it's impossible to add that on later.

Solution? Manage the expectations of your audience. Explain the limitations before they see a demo - and discuss next steps right after prototype presentation.

Developing software intensive solutions without thinking through architecture is like taking an airplane into the air. Anyone can take off, but only pilots can land.

Constantin Kostenko
Firebrand Architect®
SoftwareArchitectures.com
FirebrandArchitect.com

12 dimensions of the space of architecture

2009-12-03T16:30:00.002-05:00

On what dimensions may the discipline of software architecture change over time?

Here is what the thought leaders in the field put together during the IFIP Working Group 2.10.

12 dimensions of the space of architecture:
codification and socialization—processes by which an architect communicates architectural ideas to stakeholders. Codification refers to specification of the architecture, while socialization refers to the less formal processes by which the architecture is internalized. Socialization can happen through conversation, training, and so forth. Codification and socialization are complementary processes; they should enforce each other.
0—Codification and socialization do not occur.
10— Codification and socialization are in balance with each other; socialization becomes a process for codification; socialization and codification enforce each other and work in a global environment.
handling quality attributes
0—There is no consensus on quality attributes.
10—Quality attributes are linked to business and engineering needs and are quantitatively specified.
architectural automation
0—There is no support for architectural automation; description consists of human language on paper.
10—Language for architecture is the base language for automation.
architectural specificity
0—Reasoning is limited to specific elements (hardware, network, software, etc.) and the relationships known by the architect.
10—Architects employ reasoning about guidelines, constraints, quality attributes—self-adaptive systems.
architectural responsibility—degree to which an architect is responsible
0—There is no explicit recognition of responsibility. The worst case is having responsibility and no authority.
10—A clear definition of responsibility and authority exists for the architect’s role. Responsibility is sufficient to deliver the function and quality attributes of the system to its stakeholders over time.
accidental versus intentional architects
0—Architects have no explicit training, no career path, no formal explicit recognition, no experience threshold (relating problems to domain, development, implementation, failed, organization, etc.).
10—Architects are chosen intentionally for their ability.
domain versatility and adaptability
0—The architect has a one-track mind.
10—The architect is pragmatic and inquiring—able to organize information.
architecting process—maturity of architectural choices
0—Diverse solutions and techniques exist, but the choice is arbitrary.
10—There is a clear linkage between architecture goals and the choice of process and techniques.
technology dependency—Technology is a tool.
0—Architecture is constrained by the existing technology.
10—Architecture is fearless, specifying the abstract solution without necessarily any bindings to existing technology. Architecture is not constrained by existing technology. A fearless architecture is one that might influence future technology.
creating versus choosing an architecture
0—No previous solutions are reused.
10—The solution already exists (not accounting for the details)—looking at previous solutions and reusing them.
complexity
0—Complexity is low.
10—Architecture is produced for complicated and complex systems with emergent behavior.
interdisciplinary architecture
0—A single discipline is fully understood (e.g., information architecture, enterprise architecture).
10—Multiple disciplines are fully integrated. Stakeholders’ perspectives are met.

See source here.

Constantin Kostenko
Firebrand Architect®
SoftwareArchitectures.com
FirebrandArchitect.com

Wiki for Architecture Documentation & Managing Your Project

2009-12-02T21:11:00.003-05:00

The idea of using a Wiki to manage coordination and artifact development as part of your software development is not new. The concept and tools have matured to a point where even the most monolithic organizations involved in development of large software intensive solutions are using this.

The goal of using a Wiki is simple: keep artifacts current through collaborative ownership.

The multitude of successful open source projects using a Wiki based approach is the best justification why a community based approach works. Additionally, a perspective from academia centric sources, with associated analysis, will help you build a business case.

If you're considering pursuing a Wiki based approach consider the following resources:

Experience Using the Web-Based Tool Wiki for Architecture Documentation (thorough and free report based on actual project experiences - SEI). Blurb.
On-line collaborative software development via wiki (from Proceedings of the 2007 international symposium on Wikis - ACM)
Using Wikis in Software Development (IEEE Software)

Constantin Kostenko
Firebrand Architect®
SoftwareArchitectures.com
FirebrandArchitect.com

Where portability matters

2009-11-29T14:03:00.003-05:00

What's a good example of a software solution where portability is a paramount design quality attribute? Tethering software for mobile phones. PDANet, an application developed by June Fabrics, is a good example where designing for portability is a top design concern.

Portability is defined as the ability of a system to run under different computing environments. The environment types can be either hardware or software, but is usually a combination of the two. (Definition source)

PDANet enables PDA owners to convert their device into an Internet connection. It's hard to say if the talented folks at the June Fabrics initially planned to expand their PDANet software to other mobile OS vendors, but this application is a prime example where portability matters.

Currently PDANet supports Android, Palm OS, Windows Mobile, BlackBerry, and iPhone. While the operating systems are fundamentally different and provide different level of services to developers, the architectural drivers (i.e. architecturally significant requirements) and the general purpose of the devices is the same. Therefore the logical allocation of requirements to solution modules should be the same across all operating systems. However physical implementation would be different for each OS.

This is another great example where the benefits of software reuse come not from source code reuse, but from the reuse of software architecture artifacts.

Constantin Kostenko
Firebrand Architect®
SoftwareArchitectures.com
FirebrandArchitect.com

Impact of organizational politics on software design

2009-11-28T12:41:00.004-05:00

What is the impact of organizational politics on software design? This is a question I raised three years ago in this post and the time has finally come to attempt to answer that question.

We, as software solution stakeholders, make conscious and subconscious decisions that have a profound long-term effect on the usability, maintainability, cost, security, implementability, any-ility of a software solution. But how often are these decisions based on our personal and career motivations? Are we aware of this? Is it a good or a bad thing? If my career is centered around a certain vendor (e.g. Oracle and Java) should I or even can I viably consider technology from other vendors (e.g. SQL Server and .NET)? Would I have enough technical knowledge?

If you have an immediate thought on the impact of organizational politics on software design please leave a comment. And look for a formal invitation to fill out a survey in the very near future.

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

Essays by Paul Graham

2009-11-27T15:40:00.003-05:00

Paul Graham is an essayist, programmer, and programming language designer. If you haven't read his essays on programming and software engineering you should consider.

His latest essay on Apple's iPhone store is a good read on how business models that work for product n may not work for a product y. In this case Apple is treating iPhone apps as if they were iTunes songs, and Apple being the broker between the consumer and software producer. The nature of the development process of the iPhone apps requires frequent, if not daily, iteration of software releases, while Apple favors a lengthy review cycle before an app is published in its stores. What will it take for the developers to switch platforms? When will Apple become the evil empire? You can find the latest essay here and the rest of the essays here.

Subscribe to this blog via RSS.

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

Pricing Software

2009-11-27T15:07:00.005-05:00

We're in the business of software. That's why we all care, directly or indirectly about its pricing. Pricing affects everything - our salaries, benefits, profit. We also care about pricing because we're all are buyers of software (COTS, GOTS, development tools, etc.). And of course with respect to computer systems the cost of software exponentially outweighs the cost of hardware.

The new book, Don't Just Roll The Dice - A usefully short guide to software pricing, is a quick read, mere 84 pages, raises the right questions to get you thinking.

"How do you price your software? Is it art, science or magic? How much attention should you pay to your competitors? This short handbook will provide you with the theory, practical advice and case studies you need to stop yourself from reaching for the dice." Download a free copy here or get an a physical copy from Amazon.

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

Software engineers are also your solution architecture stakeholders

2009-11-22T10:24:00.001-05:00

It's easy to forget that the software engineers on your development team are also your stakeholders. They need a particular view of solution architecture in order to understand how they fit into the development ecosystem.

Expect to be challenged. As you walk through your vision or proposal for how a solution should be analyzed and architected be prepared to field questions from developers. More importantly, be prepared to answer those questions from developer’s point of view using terminology and analogies they understand. Since software architecture concepts deal with systemic issues of a software solution that extend beyond the routine scope of a software developer, be prepared to also educate developers on why it’s important to evaluate and address crosscutting solutions needs. You’ll have to demonstrate why a software architecture centric view is necessary and why a given approach (e.g. concentrating on architectural drivers early on) best suits a given situation. And of course the tone of your voice, your presentation style, and the pace of your communication with the development team must take into account the individual needs and backgrounds of your team members.

Remember that the software engineers on your team are also your solution architecture stakeholders.

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

Need experience planning for and executing a long term project? Run a marathon.

2009-11-03T18:44:00.005-05:00

This thought came to me on mile 21 of the Marine Corps Marathon that I ran and finished on October 29th, 2009. Planning, training for, and running a marathon is similar to executing a long term successful project. Both activities require superior commitment, strategic planning, progressive results, and a clear goal.

A marathon is different by definition - it's a solo event. However there are some points of interest.

- Goal. For a marathoner a goal is clear - finish the race in a given time period. A successful project must have a clearly defined goal that can be achieved and measured.
- Planning. Superficially it may seem that planning for training is easy. However poor planning will prevent you from training properly. And you won't be able to catch-up later (an equivalent of Fred Brook's motto of adding more people to a project that's already late will only delay a project). Long runs must be planned - including a day before and runs during the week. Planning for a long term project has the same demands. One must think through the milestones and deliverable artifacts along the way, as well as software development process that's appropriately tailored for your approach.
-Executing. Training (running) is what builds endurance, muscle, and mental capability to actually finish 26.2 miles. Concrete progress, evolving architecture from cartoons to formal documents, core code base that iteratively grows and aligns to design (plan), is the foundation of the final product.
- The race. The actual race is your test of how well you planned, trained, and executed over many months of preparation. The process of deployment to production and a cut-over (or roll out) of a system to users is your mile 10 of a 26.2 mile distance. The other 16.2 miles and how well you enable the system to handle it will be demonstrated over short time while the system is in production and used by actual users.

Why is this important?

Few people have the opportunity to be in the leadership circles of long term (2+ years) software intensive projects, but it's precisely that experience that enables us to understand the fine nuances that dramatically affect design of systems architecture. Identifying and addressing soft architectural drivers in your architecture designs is essential since it's often the organization and not the technology that places the greatest constraints on an architect.

I can't guarantee that training for and running a marathon will make you better strategist or a better architect, but I guarantee you'll have plenty of time to think about this topic when you train and when you run the race.

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

adding complexity to reduce complexity

2009-10-23T22:54:00.002-04:00

In a recent Software Engineering radio episode Markus Voelter in his interview with a guest described complexity as energy. More specifically he talked about the law of conservation of energy (energy cannot be created nor destroyed, it can only be transformed). The topic of complexity can be viewed similarly.

By addressing some nuance of complexity in a project (e.g. growth of a team) we're applying tactics (e.g. hire a manager) that may solve the issue of coordination, but introduce the issue of bureaucracy.

We have come to accept these unattended consequences (or collateral damage) as a fact of life, but it's good to remind ourselves to question why we choose one tactic over another. Some of our "trivial" decisions are binding with no undo button.

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