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®
SoftwareArchitectures.com
FirebrandArchitect.com

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™
www.SoftwareArchitectures.com

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®
SoftwareArchitectures.com
FirebrandArchitect.com

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™
www.SoftwareArchitectures.com

Thursday, December 13, 2007

Diplomacy

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®
SoftwareArchitectures.com
FirebrandArchitect.com


Diplomacy

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

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

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

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

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

Constantin K.
Firebrand Architect™
www.SoftwareArchitectures.com

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®
SoftwareArchitectures.com
FirebrandArchitect.com

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™
www.SoftwareArchitectures.com

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™
www.SoftwareArchitectures.com

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™
www.SoftwareArchitectures.com

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