Monday, January 18, 2010

Sun Tzu

“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

Sunday, January 17, 2010

Follow the money

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

Sunday, December 20, 2009

Anyone can takeoff, can anyone land?

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

Thursday, December 03, 2009

12 dimensions of the space of architecture

  • 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:

  1. 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.
  2. 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.
  3. 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.
  1. 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.
  1. 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.
  1. 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.
  1. domain versatility and adaptability
    • 0—The architect has a one-track mind.
    • 10—The architect is pragmatic and inquiring—able to organize information.
  1. 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.
  1. 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.
  1. 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.
  1. complexity
    • 0—Complexity is low.
    • 10—Architecture is produced for complicated and complex systems with emergent behavior.
  1. 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

Wednesday, December 02, 2009

Wiki for Architecture Documentation & Managing Your Project

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:

Constantin Kostenko
Firebrand Architect®
SoftwareArchitectures.com
FirebrandArchitect.com

Sunday, November 29, 2009

Where portability matters

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

Saturday, November 28, 2009

Impact of organizational politics on software design

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

Friday, November 27, 2009

Essays by Paul Graham

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

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

Sunday, November 22, 2009

Software engineers are also your solution architecture stakeholders

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