Wednesday, December 19, 2007

Engineering elegance

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 Kostenko
Firebrand Architect®

Sunday, December 16, 2007

Software Architecture Conferences and Events

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™

Saturday, December 15, 2007

Technical and Business Architecture

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 Kostenko
Firebrand Architect®

Friday, December 14, 2007

Selecting COTS software under pressure (Forrester and Gartner)

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 3rd party report should be used in any COTS software evaluation whether you’re pressed for time or not.

Constantin K.
Firebrand Architect™

Thursday, December 13, 2007


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 Kostenko
Firebrand Architect®


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™

Wednesday, December 12, 2007

Advice for apprentice software architects

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 Kostenko
Firebrand Architect®

Tuesday, December 11, 2007

Globalization and Software Architecture

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™

Thursday, December 06, 2007

Criteria For Failure

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™

Tuesday, December 04, 2007

Conceptual Integrity

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™

Monday, October 22, 2007

Evaluating SOA using ATAM

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.

Monday, September 24, 2007

Neglected Aspects of Software Architecture

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.

Thursday, September 20, 2007

Architecture is in expressly delightful

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

Sunday, September 16, 2007

Responsible Software Architecture is propelling the concept of responsible software architecture. This concept is based on philosophy that every decision made by a software architect must be conscious and must be supported by a judicious decision making process that clearly demonstrates why the chosen design alternative was selected out of a range of other possibilities.
Every decision made by a software architect is made in some context at some snapshot of time. The context is defined through architect’s understanding of personal capabilities, requirements, constraints, financial resources, time, capability of the team, etc. The context changes over time, so it’s imperative to document the background against which a decision was made. When someone questions a design decision or suggests a better solution an architect must provide a scientific justification of his or her decision – without it architect’s credibility and the credibility of the solution may be compromised.
The concept of responsible software architecture is very powerful, but few architects live by it. Think about two or three most recent software architecture design documents that you reviewed. How many documents clearly explain the way key architectural decisions meet business drivers and why selected architectural approach is better than listed alternatives? Not every decision needs to be documented with an elaborative set of alternatives, but all key decisions need to be explained. Key decisions are architecturally significant choices that if changed have a profound impact on multiple quality attributes of a system.
A responsible software architect must sincerely believe that a business problem, and not technology, drives the solution. Technology may be the core vehicle for delivering the solution, but it’s not the driver – this is a paramount concept. Because technology is not the driver a responsible architect must be able to initially reason about a solution without technology specific terminology. The point here is that selection of a technology (platform, development tools, COTS software, etc.) is an architecturally significant decision that constraints the solution. An architect must be able to provide a judicious explanation as to why selected technology was chosen. Once that decision was made it’s only natural to think within the context of selected technology.
Some software architects have too much vested interest in a given technology so they only design solutions with that framework in mind. This clearly limits the range of solution alternatives, but it’s not as limiting as reusing the same architectural approach from project to project without justifying the reason for doing so. For example an architect who designed web based applications using MVC architectural style for the past four years may be inclined to use it on the next project even if a Front Controller style or an AJAX based pattern may be more appropriate. Similarly if an architect is used to a working with a process intense SDLC he or she may push for it without realizing that a new project requires agile JAD/RAD approach due to its research and development nature. The latter examples demonstrate the proverb: “When all you have is a hammer, then everything looks like a nail.” For an architect to be responsible he or she must question their decisions and make sure that appropriate audience is able to understand the reasoning behind the decisions. is currently establishing a Center for Responsible Software Architecture. Join the discussion on responsible software architecture in a specially created forum. Each post will earn you a chance to win Evaluating Software Architectures: Methods and Case Studies book (through October 15 2007). Registration required to view and post.

Firebrand on duty: Constantin K.

Friday, September 14, 2007

AJAX Application Architecture

A friendly reminder: a decision to implement the UI of a solution with AJAX has architecturally significant implications. There are different flavors of AJAX implementations and each has a set of tradeoffs associated with bandwidth consumption and security. Read this MSDN article for details.

Firebrand on duty: Constantin K.

Thursday, September 13, 2007

Beyond Software Architecture - quick read

A dated (2004) yet applicable interview with Luke Hohmann, author of Beyond Software Architecture: Creating and Sustaining Winning Solutions (Addison-Wesley, 2003).

Make this a quick read - Luke Hohmann provides interesting views on the human points of software architecture with respect to building enterprise software with agile methodologies in mind.

Some notable points:
- In the beginning architecture should be complete, but it’s OK for it to be immature. This is exactly what Fred Brook’s identified in his 1975 masterpiece “The Mythical Man-Month” (p. 94) when he identified the concept of conceptual integrity as the most important consideration in system design.
- Software architecture is a communication medium

Part 1, Part2, Part 3.

Constantin K.

Friday, September 07, 2007

Microsoft's Reference Architecture

A software architect must have a comprehensive understanding of the technical environment in which a software solution will reside. Mature and usually large organizations usually have volumes of Enterprise Architecture (EA) that contain guidance and identification of the as-is state of the enterprise and the future evolution. The volumes of EA usually represent different levels of abstraction, but have a common theme centered on a business domain. Parts of the EA are meant to be used as reference architecture to guide a software architect in design of a solution so that it fits snuggly into the existing enterprise and so that a solution can evolve graciously.

Microsoft has developed a comprehensive reference architecture that for its Windows Server platform. It’s a “detailed reference architecture, tested and proven in labs, that yields valuable implementation guidance for meeting the requirements of an enterprise.” Even non-Windows enterprise architects will benefit from the recommendations in the Microsoft’s reference architecture documentation.

For each type of service reference architecture contains an introduction, a blueprint, a planning guide, a build guide, and an operations guide. Out of many services covered some notable are network devices, storage devices, firewall, certificate, backup, network, directory, file, data, web application, middleware, and messaging.

Microsoft’s reference architecture is well organized, easy to use, and very comprehensive for both Microsoft and non-Microsoft centric architects.

Home page | Comprehensive download MS Word documents in installer

Firebrand on duty: Constantin K.

Thursday, September 06, 2007

Startbucks The Way I See It #240

Sometimes there is more wisdom on the outside [of your Starbucks cup of coffee] than on the inside. From "The Way I See It" series #240 applies fluidly to software architecture:

If you can’t visualize it, don’t build it.
-- Constance Adams
Space architect and National Geographic Emerging Explorer.

Firebrand on duty: Constantin K.

Friday, August 10, 2007

Architecting With 3rd Party Components: "Trust, but verify"

A proverb: “Trust, but verify” should always resonate in software architect’s mind when a decision is made to use a component that the architect does not directly control. This component may be a COTS software piece or an enterprise library developed by someone else. This becomes especially important if that component is part of the project’s critical path (e.g. a communication infrastructure component).

For example, the enterprise may require every solution to use component Foo to obtain a security token. Or the enterprise may require component Bar to be invoked to pass through messages so that certain information can be collected for enterprise auditing purposes.

Unless you have previous experience architecting with that 3rd party component take a safe path. Identify the elements of your solution that will rely on the 3rd party component. Then thoroughly analyze the external component for each quality attribute requirement that is associated with the software architecture element that uses that component. If the documented performance, security, availability, and other quality attributes match the needs of your architecture proceed with caution.

Think about mitigation strategies (alternative implementation tactics) in case the 3rd party component does not live up to the promised expectations. For example, can auditing functionality be done as a batch mode instead of real time? Can an alternative protocol be used for issuing security tokens?

As the implementation commences inspect the properties of the promised quality attributes with the intensity that is equal to the role that the 3rd party component plays. If a 3rd party component is part of the critical path of a project conduct intense quality attribute related tests prior to committing your architecture to it.

For designing with COTS software see this article.

Remember: “Trust, but verify”

Firebrand on duty: Constantin K.

Thursday, August 09, 2007

Revisiting the definition of software architecture

When was the last time you thought about the definition of a software architecture? It has been quite some time since I read the definitions posted on the SEI’s Community Software Architecture Definitions page. Some interesting definitions:

Eoin Woods (Software Architect, Investment Bank, London, UK): Software architecture is the set of design decisions which, if made incorrectly, may cause your project to be cancelled.

Adu Matthaeus (Systems Architect, Eikon, Centurion South Africa): A configurable skeleton of any kind of software beast on which you hang implementation specific muscle to make it live.

Jeff Winter (Software Engineer): … Architecture is necessarily a series of abstractions, depicting details relevant to one perspective while suppressing details relevant to other perspectives, and therefore expressed as a series of complimentary views. To say what those views are, you must embrace some ones method or make up your own.

Steve Wright (Consultant - Sr. Data Architect, Knowledge Management, Boston, MA): Architecture is the set of decisions that must be made at the enterprise level before specific applications are designed and built in order to provide conceptual integrity and sanity across the enterprise’s systems. Architecture includes a decomposition of the systems into separate orthogonal viewpoints along with the enforced rules that enable this clean decomposition and isolation of design viewpoints. This is done so functional (application requirements) and non-functional (system qualities) and other aspects of the application system may be defined and built by independent specialists in their specific field. An architecture not only divides the system, it also divides the roles and responsibilities of those who work with the system into separate organizational concerns and disciplines that are conceptually tractable and can be effectively managed.

Balakrishnan Thiruvadi (Technical Manager, HTC Global Services, Chennai, India): It is an art of defining, implementing, maintaining system and software environments that will assist and grow with business requirements.

Tim Simmons (Student, Southern Adventist University, Nashville TN USA): The architecture of a software system is its very essence. It is not merely a schematic showing interconnected components, but a description of those components and the way in which they interact. It is the foundation upon which the entire system is built.

Firebrand on duty: Constantin K.

Wednesday, August 08, 2007

Software Architecture Discipline Splits

We dreamed about the software architecture discipline becoming a mature discipline similar to the way civil engineering has evolved over time. To a certain degree this has become true: a unique set of skills is not required to develop a basic accounting back-office suite or a large scale eCommerce site. Banal solutions are reproducible by anyone with basic software design knowledge. This is good, because seasoned architects are now reaching out to solve more challenging problems.

Up until now software architects were doing two jobs under the same title: mature software engineer and mature software designer. [Note that the word 'mature' is used over 'senior' since age does not equate to seniority or ability to design complex solutions.] The software architecture discipline will eventually split into those who concentrate on the art of the discipline and those who specialize in the science of the discipline. This is inevitable due to the ever-growing complexity of responsibilities a person with a software architect title.

All software architects need to have experience from the trenches (working on serious projects in the real world) doing programming, design, and experience in all other parts of the SDLC experience. However, the architects concentrating on the 'art' aspects of the discipline will find themselves spending more time understanding and eliciting the business problem and conceptualizing the solution. The architects concentrating on the 'science' aspects of the discipline will provide cross-check the concept and provide insight on concrete implementation options. The soft side of the architecture discipline will deal with the human aspects, while the hard side of the architecture will address technical aspects.

The need for further concentration by means of splitting architecture responsibilities into soft and hard sides comes from increased demand from the business users to develop solution that solve a business problem, as well as the need to deal with the continuously growing complexity of implementations and overflow of new technologies and tools.

Constantin Kostenko
Firebrand Architect®

Friday, July 20, 2007

Question assumptions or live with consequences

Don’t assume that the knowledge you have or recently acquired is possessed by your stakeholders, customers, and clients. Even non-architectural knowledge, such as existence of alternate SDLCs, may not be known by those around you. This is a big deal, because a project may be moving forward, on a wrong orbit, while all key stakeholders assume that it’s the only way.

As an architect it’s your responsibility to challenge the assumptions and expect a reasonable explanation. The same way you, as an architect, expect to be questioned about the tradeoff decisions and alternative designs.

Firebrand on duty: Constantin K.

Wednesday, June 13, 2007

On Time and on Budget

Fresh from the June 2007 PMI magazine ... according to 2006 Chaos Research a study of 10,000 global software projects (value at $100K to millions), completed between October 2005 and November 2006, reveals that only 35% deliver on time, on budget, and within the requirements. That's an improvement from the 29% figure reported in 2004 by The Standish Group.

Firebrand Architect on duty: CK

Tuesday, May 15, 2007

Security for Software Architects

Security is about managing risk. No usable system is 100% secure – that’s a fact. Of course it is possible achieve 100% security by placing a system in a physically guarded bank vault and disabling all communication mechanisms. Based on how the society uses software systems it's clear that such approach is not suitable for most usable software systems. It’s not possible to defend against all vulnerabilities, not only because organizations don’t have the resources, but because new threats arise daily. It’s the architect’s job to work with the system stakeholders to seek the balance between risks and resources.

Read a new article on this topic on It's written is for both seasoned and apprentice software architects in mind. Security has always been an important topic, but with rapid software evolution software architects are forced to pay more attention to this quality attribute. In not so distant past, before standardization of various protocols (e.g. TCP/IP, SMTP, etc.) most business systems were isolated and existed within the physical boundaries of proprietary communication infrastructure. At that time there was little, if any, electronic data exchange between organizations. The subject of security did not become prevalent until the need for interconnectivity and interoperability emerged and the cost of security breach became a real cost to business.

Firebrand Architect on duty: CK

Thursday, April 26, 2007

Control Your Engine!

Imagine you’re building a car. You get car parts, including an engine, from various vendors [think COTS software] and different people help you put it together along the way [think contractors & subject matter experts across divisions]. You’re making progress – you have attached the wheels and can push the car through the product line [dev / test]. Now you’re reached the end of the product line. It’s time to start the engine and drive [pilot stage]. The engine turns but doesn’t start. After troubleshooting and double checking your work you find out that the engine [think messaging infrastructure] doesn’t work. The fuel tank is full [messages are sent from originator], the fuel line to the engine is full [message path is traceable], but the engine won’t process the fuel. When you ask for help from the engine integrators they blame the fuel line.

The engine is the mechanism that makes a car move in a similar way that a messaging platform makes software components work together.

The point of the analogy is to remind architects that in the environments where they are constrained by organization’s enterprise architecture the communication patterns and related infrastructure that glues their application may already be predefined. No matter how good the infrastructure products may be, blindly assuming that the people operating the infrastructure are able to configure it for your needs is a recipe for disaster. This is especially true for quality attributes of a system that require high volume of transactions.

In environments where you cannot control the communication infrastructure always design with a backup in mind.

Firebrand Architect on duty: CK

Tuesday, April 10, 2007

Design constraints

Nothing nullifies the effectiveness of a software architect more than project manager’s directive to design in three month increments for a system that will stay in service for 15 to 20 years.

Not thinking about the future of a system is a sure way to guarantee unpredictability when it comes to the system quality attributes such as modifiability and extensibility.

Wednesday, February 28, 2007

Business Improvement Through Better Software Architecture

In the 10th edition of The Architecture Journal, published by Microsoft, a son & father pair have done an outstanding job describing architect roles in business software development. It’s not very often that you come across such a well written, eloquent, yet terse piece of writing that energetically captures the responsibilities of architect roles and the relationships between those roles.

The authors, Sten & Per Sundblad, state in the opening paragraph that “business software exists for one reason only: to support the business and its activities … there is no other reason for business software.” This is the premise of their philosophy and a fact that software architects often forget. Countless articles have been written over the past five years on lack of alignment between IT and business. Few of those articles presented the issues and solutions with proper level of abstraction that made reading this article equivalent to reading a really book that you don’t want to end.

The article is authors’ perspective and by no means a standard, but it’s a good use of your time and deserves placement in the Essential Selection.

Firebrand Architect on duty: CK

Sunday, February 25, 2007

Asking for help - a mature decision

A software architect is in charge of the overall technical solution – there is no question about that. But a good software architect also knows his limits and requests assistance from subject matter experts on the issues outside of his or her knowledge base. Technical skills are only 49% of software architect’s skill set.

For example, a software architect with experience in web portal development is assigned to lead a project for a web based case management system. If similar technology and the same web based paradigm are used on the new project this is a reasonable request on behalf of the business management.

After studying case system requirements and after examining the quality attributes an architect sees that the system will require a highly sophisticated authorization system in order to ensure that the right users get access to the right parts of a case at the right time. If complex resource authorization is not architect’s technical strength, then a subject matter expert must be brought on board for consultation. This is not an insult to architect’s competency or ability to perform her job; it’s a mature decision that will improve the odds of designing the right functionality that serves users’ needs.

There are cases when financial constraints prohibit acquisition of external subject matter experts. Then it’s up to architect to make the best of the situation, but such decision should be documented as risk. It’s a well known fact that it’s not possible to retrofit security into a system without breaking system architecture.

Firebrand Architect on duty: CK

Sunday, February 18, 2007

EA pillars - a view

Enterprise Architecture is probably one of the most overloaded technical terms. There are many groups wrestling for control of the definition and its associated taxonomy. This of course causes architectural mismatch between systems, concepts, departments, and organizations.

The following post by Paul T. Preiss, President of IASA, calls for examination of the essence of certain architecture specialties (software, infrastructure, and business) to derive an objective list of knowledge foundation blocks. This post is a great start to future collaborative work on building bridges between different frameworks and methodologies.

Wednesday, February 14, 2007

Duties of a Software & Solution Architect

What does it mean to be a software architect? How about a solution architect? There are as many opinions as definitions of software architecture. It is clear that a software architect is not simply a senior software engineer. Responsibilities of a software architect cover a wide array of skills outside of technical field of knowledge. The listing below is a series of opinion pieces by various bloggers and web sites on the definition of a software and solution architects.

Constantin K.
Firebrand Architect®

Wednesday, January 31, 2007

Effective Presentations by Software Architects

In an earlier post the topic of clear, concise, and terse writing was presented. This post raises the importance of effective architecture presentations. It’s critical for every architect to be able to create and deliver effective presentations in an amount of time allocated. The following tips, derived from experience, should be kept in mind. It is assumed you’ll be using a Power Point or similar software.

  1. Mind your audience. It’s imperative to set the tone and presentation content based on the audience and audience’s expectations. If someone requests a presentation on the architecture of a system find out what they want to get out from the presentation. This will make the process of creating the presentation easier and your results will be measurable.
  2. Mind your time. If you’re allowed 30 minutes for presentation you will only get 30 minutes. This is especially true with angel investors, venture capitalists, executives, and anybody who simply values their time. Extenuating circumstances aside – running out of time is a result of poor preparation.
  3. Preparation is essential. Throwing some diagrams together and trying to wing it will result in poor quality. The presentation must have a flow that tells a story that your audience cares about. Prepare a handout outlining the key aspects of your presentation, but only distribute it when you start speaking.
  4. Be professional. Your presentation slides must be in a consistent format. Font, positioning, color scheme must be uniform.
  5. Practice. Most people fear public speaking. Those who don’t are unique or liars. When you hear yourself talk aloud while standing you’ll feel the areas of the presentation that do not transition well. Practice presenting in front of an audience even if it’s just one person who doesn’t know anything about software architectures. Practice will logarithmically build up your confidence unless you don’t know what you’re talking about.
  6. Know your subject matter. The audience will be able to tell if you don’t know what you’re talking about – just by seeing your gestures, tone, and logic. Anticipate tough “why” questions and be able to respond intelligently. After all an architect must always explain why a give decision was made or not made.
  7. Backup slides. Include backup slides at the end of your presentation if audience wants more detail on some part of a system presented earlier. Backup slides don’t need to be polished.

Remember that as a software architect you’re the chief spokesperson for a software system.

- Firebrand Architect on duty: CK

Wednesday, January 10, 2007

Architects need to improve their written communication skills

Effective written communication skills are essential for every software architect. Expressing your ideas clearly, tersely, and effectively is paramount. If your audience does not fully understands your vision or design, then you’ll have to build (and probably fund) the system yourself. It is your responsibility, as the architect, to ensure that your readers understand your ideas.

Written communication is important, because that’s the only effective way to communicate with a large number of people who may be geographically distributed across the world in different time zones. A single software architecture design package is often the source of reference for hundreds of people on a large scale system or a system of systems.

The international software engineering community recognizes English language is the standard language for cross cultural communication. Therefore it is paramount for any software architect to improve their skill set of the written English. Improving written English is probably even more important than improving oral English.

There might be many guidebooks for improving your writing, but my colleague and scholar of the English language recommended only one book: “The Elements of Style” by William Strunk. The book has been in print for a few decades. It is available in the original edition, the illustrated hard cover edition (my copy), and the fourth edition. The content is about the same across all of the editions. This book is a definitive reference guide for an everyday writer. The book has no prerequisites and can (and should) be used by every technical person. After using this book you will notice that your ideas are shaped more clearly and your sentences are easier to understand. This book belongs on your technical books bookshelf.

Sunday, January 07, 2007

Beyond technolgoy in technical books - joy for architects

The winds are changing – the software engineering mainstream practitioners are finally starting to value the importance of the human aspects of software engineering. And that’s only good news for software and solution architects.

If you’ve been reading some of the newer technical literature, such as the Pro [Microsoft] BizTalk 2006 book, you would have noticed one paramount shift in the book’s introduction part. First the authors provide the core overview of the BizTalk architecture, as expected, but then spend the next chapter going over various human and organizational aspects of running a project.

This is important. This shows a conscious effort on behalf of the authors to convince the reader that establishing a technical and management structure is essential to the success of the project. The book provides brief guidance for setting up communication chain of command, provides an example of a rudimentary build and deployment process, and emphasizes on the importance of organization and team work.

Most books a specific technology only concentrate on technology and often neglect the human aspects of software architecture. The Pro BizTalk 2006 does a fine job of emphasizing, if not requiring, that software engineering practitioners follow best practices when utilizing BizTalk 2006.

- Firebrand Architect on duty: CK

Blockchain learning path for Enterprise Software colleagues

I wrote this post to document my learning path of blockchain concepts and Ethereum technologies while keeping my “new to blockchain” collea...