Firebrand Architect®

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

See the ecosystem, not the forrest

2009-10-21T23:52:00.003-04:00

As a software architect one must see a forest and not just trees. As a Firebrand Architect® one must see an ecosystem and not just the forest.

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

Architecting Windows 7

2009-10-20T21:35:00.002-04:00

"To Rebuild Windows, Microsoft Razed Walls " is the title of an article in the October 20th 2009 edition of the Wall Street Journal.

There is something interesting about Microsoft's software development approach taken for Windows 7.

The article attributes the perceived initial success of Windows 7 to a different, more humble, approach taken by Microsoft and the Windows 7 team. While the quality of the operating system is yet to be determined by the real world tests it appears that the design and execution of the product was different.

"A key problem was that the Windows team had evolved into a rigid set of silos—each responsible for specific technical features—that didn't share their plans widely. The programming code each created might work fine on its own, but cause technical problems when integrated with code created by others."

This article exert contains a key observation. Operating system development can be viewed as a set of semi-independent silos united by a kernel. But it appears that the demand for effective integration of various operating systems components is essential for successful end-to-end experiences. And this is the key - Vista was not developed with the user's end-to-end perspective at all stages and that resulted in what we have today. For Windows 7 Microsoft appears to have taken a different approach.

And while the article doesn't use the words such as "architecture" of "design" it appears that Microsoft took a user and architecture centric approach to unify the work of all developers under an umbrella of clear objectives (which probably translated into specific quality attributes). For example, "An important new objective called "quieting the system," which sought to minimize windows and dialogue bubbles—such as security warnings—that pop up on screen during the normal operation of the PC." Another key feature of the operating system is a touch-sensing function that adapts to user's strokes and does not simply mimic a mouse. It's clear that a number of cross-cutting features were implemented in the operating system and initial response to the quality of software has been favorable.

It appears that highly collaborative engagements with an end-to-end perspective were enacted as part of the software development process; a known design approach finally taken by Microsoft at the operating system level.

You may find a link to the article here (available for about two weeks).

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

What kind of leader are you?

2009-10-18T11:30:00.004-04:00

An architect role is a leadership role - that's a fact. Your leadership style and your capability to lead will enable or cripple your team.

There are many leadership gurus with thousands of books on the subject. For the purpose of this post and to keep things simple I'm using John C. Maxwell's five levels of leadership strucutre. I've been to his lecture and I like the simplicity of his approach. John's repertoire of books is significant (johnmaxwell.com), but at its core the following structure stands.

Level 1. People follow you because they have to.
Level 2. People follow you because they want to.
Level 3. People follow you because of what you have done for the organization.
Level 4. People follow you because of what they have done for them.
Level 5. People follow you because of who you are and what you represent.

The first level is self explanatory.
At the second level your leadership depends on the relationships you build with the people. At this level you're connected and engaged. As John Maxwell says: "you listen, learn, and lead - constantly."
At the third level you're clearly demonstrating how you improve the bottom line. People see the results and performance that's the result of your leadership. You add clear value.
At the fourth level you're developing other people to be as effective as you are in leading others. People are attracted, because they want to be like you. Loyalty becomes very strong.
The last level, achieved by few in life, is given by others as a result of your lifetime achievement as an effective leader (think Gandhi, Churchill).

What kind of leader are you?

Watch for future posts on how to grow your level of leadership.

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

PDC 2009

2009-10-17T19:39:00.002-04:00

If you're on the Microsoft bandwagon, then PDC 2009 is for you. http://microsoftpdc.com/

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

You, as an architect, must take the initiative

2009-10-16T23:46:00.005-04:00

Simply by having an "architect" word in your title or role description automatically puts a heavy burden on you. Automatically people will assume, and rightfully so, that you have the responsibility of gathering and synthesizing information and making early design decisions. Your colleagues and stakeholders will expect guidance from you - well before and after the official software design phase commences.

As an architect you should be very well aware that you're under a spot light at all times. Nobody will ever tell you that the right time has come to start architecting. If someone has to tell you that now is the right time to start architecting it means that you're not paying attention. There are, of course, times when it appears that no action is required. For example, requirements are too fluid and insufficient to start designing, or a business case for a solution has not yet been well defined, or perhaps the funding has not yet been approved. The times of uncertainty are the times when the rest of the organization / team needs you the most.

As an architect, or rather as a Firebrand Architect, you should take initiatives to position the flow of the project / solution to enable you and the team make disciplined rational decisions. If you take the initiative, then you control the pace of the development. This does not mean that you have to fight for control with marketing or the R&D group. This means that you need to proactively monitor the environment and understand how the ongoing developments will constrain your downstream design space.

For example, if the requirements team is struggling with analysis try to evaluate if they are diving into details too soon. User your software engineering skills. Perhaps they are lacking a coherent vision document, lack requirements gathering structure, or simply lack resources. Determine if you can provide high level help based on your previous experiences. In the case of writing a business case you can provide insight of how this type of a solution would blend with existing systems and help determine time to market.

If you control or influence the pace and flow of your project progress before and after the software design phase you maximize the design surface area with which you can work to create software that's fit for purpose when the official design phase commences.

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

Interviewing future leaders at Carnegie Mellon - Heinz College graduate students

2009-10-15T18:27:00.006-04:00

It's truly inspiring to speak with young graduate students who passionately feel about positively changing the world. This week I was asked to join a small team interviewing graduate students (Carnegie Mellon - Heinz College) who are seeking employment in late winter or late spring to put their degree to a good use.

The most exciting part of the interview was seeing how most students in my group were able to discuss concrete problems from an end-to-end perspective. Here is a general observation about the future leaders:
- they can effectively organize and leverage team members' time and skills; they are have a disciplined and patient approach for deciding who would lead and how the tasks should be distributed
- they continue to learn and care a whole lot about learning opportunities their employer offers
- they are open to new ideas and observations; change is not a distant concept, it's a way of life
- they are data driven at all the right places; they understand the value of business intelligence and they know how to formulate a problem so that the right data is gathered and analyzed so that the right insight can be provided in a timely manner
- they are professional and passionate
- they are fearless and ready to tackle new challenges
- they know they can and shall change the world

On my journey to Pittsburgh I was wondering if this trip was the best use of my time. On the way back I realized that I learned from the students as much as they learned from me. This was time well spent.

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

You can't rely on your knowledge of patterns alone to architect

2009-10-12T22:21:00.005-04:00

Design patterns are used for solving a specific known (routine) problems using a prescribed approach. For architects the patterns are the building blocks of the systems we create. An architects needs to have a working knowledge of a diverse library of patterns spawning various levels of granularity and applicability relevant to his or her domain.

It's important to note that all patterns fit somewhere on the spectrum of design decisions. All patterns can either be refined by lower granularity design patterns or rolled-up into larger patterns. However there are exceptions to these rules impacted by strategic vision and availability of resources (constraints). This is what makes architecting fun.

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

Example of a solution not fit for purpose

2009-10-12T17:00:00.002-04:00

Five years ago I architected and (with a small team) implemented a COTS centric solution (Microsoft and ProSight technologies). The design process was supported by clients and all phases of SDLC were executed well. Architecturally significant decisions were made based on factual findings. For example, after an evaluation of enterprise environment we concluded that the necessary bandwidth required by COTS software wasn't available and a decision was made to allow select user groups to access software directly on a server via a remote desktop connection. Other user groups would use web interface for simpler tasks. We estimated the number of users, application load cycles, data call spikes, etc.

In the end we crafted a seven sever solution with load balanced web front ends, separate logic server for data crunching, and a set of very powerful database servers (in 2005 fully loaded HP ProLiant 570 were the best of breed).

At UAT the solution surpassed technical and usability expectations and was well suited to handle over 3,000 users. So why is this solution (still actively used) not fit for purpose? Because the number of actual users is in the hundreds and not thousands. The client over estimated the adoption rate of the solution. The next year the business processes changed and the organization chose not to invest into reconfiguring the solution to enable the full 3,000 users to use it.

On a surface it appears that the architect is not at fault. But should the architect thought about user adoption? Should the solution have been designed with fewer servers from the start? In this case the risk of building for max size was the right choice, because this organization is large and slow moving. Procurement takes months and budgets are often unpredictable. Without knowing the history of this solution it's clear that this is an overkill and the solution is not fit for purpose (waste of computational resources). A potential way out is to scale down through virtualization, but of that's a story for another day.

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

What exactly is "fit for purpose"

2009-10-11T17:40:00.002-04:00

Firebrand Architect® adopted the "software fit for purpose"™ mantra for a very good reason. It's the architect's job to make and bear responsibility for decisions that can make or break a software solution. Of course an architect is not the only factor in the success of a solution, but clearly early design (and approach) decisions come with high cost.

Deciding on what's fit and what's not fit, and how to reach the right balance, is a subjective and difficult question to answer. This is why software architecture (and various other flavors of IT architecture) will always be part science and part art. This is why there will be more and more architecture specialists (e.g. security architect, performance architect) over time as complexity of software solutions (or rather system of systems) grows. And this is why architects of all flavors need to have a well rounded understanding of the operating environment - including human aspects.

In order to convince oneself that something is the right fit takes discipline, experience, knowledge, and willpower. Having the willpower to question your own decisions as well as decisions and positions of those around you is a quality of a person who is a Firebrand Architect®. Ensuring the creation of software that's fit for purpose requires pushing the limits of the ordinary. It's a quality that doesn't come easy, but it's a quality that can be developed over time.

The important adjective here is the word "right." It's the right balance of requirements, constraints, patterns, decisions, and construction approaches that enables the creation of software fit for purpose. Striving for perfect or best is not a viable approach in most situations. See next post for an example of a solution not fit for purpose.

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

Software Engineering education for your clients and customers

2009-10-10T20:42:00.003-04:00

This is not a "how to" post, but a reminder to build in time for client and customer education on software engineering. There is only one person in this world that thinks exactly like you, and that's you. Everyone else around you, even your long term colleagues, have a different perception of problem, solution, and approach even if you work well them.

This observation calls for two actions:
1. Build time (directly or indirectly) into your project to educate your clients and customers on the discipline of software engineering and software architecture. You'll have to spend time convincing them that a disciplined approach to creating software is not a choice, but the way of life.
2. Create a mini curriculum, or at least talking points, ahead of your engagements with clients and customers. You need to be proactive in your education sessions and they always should be done in the context of a specific business problem or a solution you're working on.

If a client or a customer has real world experience with enterprise grade software development or implementation you must gauge past experience. On a positive side a client may be receptive to your disciplined approach. On a negative side, if a client had negative experience, you need to understand client's perception of the software development process and demonstrate how your approach is better.

And most importantly - pay attention to the right approach. Selection of agile or highly structured software development processes and degree of requirements elicitation and software architecture analysis differs from problem to problem. Understand your client's situation and explain why your approach makes sense in a given situation.

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

Writing down solution concept - a practical quick start guide

2009-10-07T16:15:00.002-04:00

As an architect you’ve been tasked to come up with a business and technology solution. Where do you start? You probably have a lot of ideas and concepts in your mind. The best way to get started is to offload your ideas and concepts into a list – or better yet on paper or whiteboard (or Visio). As you dump ideas down you’ll be tempted to expand and link the concepts right away, but first concentrate on writing everything down.

The next step is to create a “back of a napkin” business perspective of your solution. What are the key components and functions? Perhaps a shopping cart, an inventory management thingie, a brain to pull it all together, and a payment processing element. Use whatever media you’re most comfortable to quickly sketch a business architectural cartoon. Show how things are linked.
Allocate all elements from your list at this stage.

The disciplined part of you may be tempted to think about decomposition using proper architectural perspectives (static, dynamic, and physical views). You may be thinking about the meaning of links between boxes. This will come later, but you’re still at a very creative stage. Keep on moving.

Next, create components that would implement / support the business elements and sketch them in the context of your existing operating environment. Again, draw loose associations between existing systems and your components. Now go one level down and decompose each of the components into sub elements (if appropriate).

In my most recent exercise I used a standard sheet of paper cut in half as my work space. As I created sheets I numbered them in sequence of creation. This allows you to spread them on a table (or tape to a white board) without the fear of forgetting your chain of thinking and decisions.

Put the resulting stack of sheets away for a few days.

Now you have enough material to create a discussion document. Use your favorite diagramming tool to create a presentation that’s targeting proper audience. Be sure to remove highly technical material out of the presentation targeting non-technical stakeholders.

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

Using consultants for big picture insight

2009-10-06T17:46:00.001-04:00

Few software engineers and software architects have the privilege of being meaningfully involved in so many initiatives that they see the big picture of where the organization is going. This does not apply to all architects and all organizations, so this tip is for large organizations.

If your organization is using consultants to help on various projects you should consider tapping into their experiences for a big picture perspective. Yes, they will ask you to fund the time they spend gathering the data and creating a presentation, but the insight may be worth the time and money. It’s always very beneficial to have a third party provide feedback on the elements you don’t have time or ability to see.

Caveats: only work off the existing trust level. If there is no trust between you and a consulting group you won’t benefit from provided insight. Pay attention to the recommendations and the consultants’ line of work – they may be consciously or subconsciously selling you more work (and you should expect them to do so). Reflect on the findings and synthesize with your current and future activities. This may be a good time to review your organization’s strategic plan and objectives (if it exists).

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

What breaks my heart

2009-09-30T21:27:00.000-04:00

In a fruitful conversation with this organization's software evangelist we discussed the right (economical, efficient, simple, verifiable, results centric) approach for designing a solution to address a pressing knowledge management problem. The explosion of electronic data over the past ten years has really caught up now. The solution would use organization's existing infrastructure assets (both software and hardware) and can be implemented to serve 4,000 users in the production environment under 6 months with 4-7 FTEs.

Evangelist's caution statement? Political barriers within the core IT organization won't allow for creation of the system, because it doesn't include the other 20,000 employees in other divisions who may need something similar. This is the heart breaking part. The core IT organization cannot dedicate its resources to reduce the burden for 4,000 employees, and lack of trust between a business division and the core IT organization prevents business unit from funding and creating the system on their own. Even if it would eliminate the waste of about 100,000 worker hours a year.

Solution? Get off the ground by bolting on this solution to existing projects. Find supporters in the core IT organization and build personal relationships with them. Continuously consult and involve them in your decision making process even if the architecture has been set. Be prepared to modify your architecture to fit their personal and political views. Achieve early success with core stakeholders, i.e. implement low hanging fruit functionality, and let your users talk up the success of the system. Conduct pilots to demonstrate results and recruit passionate users to be your biggest in the field advocates. This "from the trenches" approach may backfire if not planned and executed properly, but this case may be a good candidate where it's worth taking calculated risk.

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