Saturday, January 31, 2009

Simple Architectures for Complex Enterprises

Measuring complexity of business processes and software solutions that support them is a difficult task. Roger Sessions in his Simple Architectures for Complex Enterprises book provides an excellent math (logic) based approach for examining Enterprise Architecture complexity without getting into formal methods. The philosophy behind the approach is superb and refreshing. The chapter on technology approaches will be obsolete soon, but chapters 1 - 5 will be applicable for years to come.

Constantin K.
Firebrand Architect®
SoftwareArchitectures.com

Tuesday, January 20, 2009

A new era of responsibility

As president Barack Obama was delivering his inaugural address on January 20th 2009 I was taking notes on how his theme of a "new era of responsibility" will affect my clients and my colleagues. Software architects have a tremendous power to make or break a system. With such power should come a great level of responsibility. But how often do you hear architects taking full responsibility for the design of a software solution? How often do you hear architects clearly justify why a certain design was chosen among an array of alternatives and how specific tactics will address domain specific business needs? Just check any software licensing agreement: [company] makes no warranties, express or implied ...

Has the time come for responsible software architecture and responsible software engineering? As a software architect how will you handle a new era of responsibility?


Constantin K.
Firebrand Architect®
SoftwareArchitectures.com

Thursday, January 01, 2009

Dealing with the bus problem

When a "bus problem" becomes a reality it's critical to address the human needs first. This post does not provide guidance on how to deal with loss, but if you're in a leadership position you need to know how to appropriately respond or where to go for help.

Ultimately if you hold a key position in your organization (e.g. reputable architect or a trusted advisor) you may be called upon to help right away. Your first order of business should be to get the software solution up and running by all means necessary. Be prepared to look at the source code, log files, incomplete documentation, conduct interviews with frustrated users. You will be looked upon as a savior whether you're ready or not, so you must be prepared to act like a Swiss army knife. In this situation the pressure is high and failure is not an option.

Here are the guidelines to help you think when under pressure:
- Create a plan of action. Write down everything you think you need to do. Use this list as a start.
- Understand the business need and function of the solution. Bus problems usually don't occur on properly managed large scale solutions with a clear mission. There is a very good chance the solution affected by a bus problem supports informal business processes that you don't know about.
- Learn everything you can about the solution. Seek people who may have worked on the previous version, seek hard copies of presentations and documentation if soft copies are not available.
- Think about the technical aspects of the solution. Based on the technologies used and your experience with the application (if any) you may make some assumptions about architectural patterns used. But be careful assuming that the patterns are being used correctly. An opportunistic solution is very likely to have improperly used (or misused) architectural patterns or simply poor implementation. Hope for the best, but expect spaghetti code.
- If you're not proficient with the technology used find a smart software engineer to work with you side-by-side. At this stage this person will be your partner - not a subordinate.
- Be aware of the political landscape. If the solution in question was developed and managed by a different organization devise a strategy with your senior leadership to diplomatically address this issue. The organization owning a failed solution may be well aware that they were irresponsible by letting the affected solution operate in such manner. Think about an exit strategy for the responsible organization to gracefully "save face."
- Write a short draft proposal (1 or 2 pages) of how the broken solution should evolve into a mature environment so that it can be supported by your organization's IT. You will have ideas as soon as you start looking at this problem so you may as well write them down from the perspective of your organization's computing infrastructure.

This is not a complete list, but it will help you handle the knee jerk reaction you may be expected to perform. Act quickly, but systematically. Understand the business value of the solution that's hidden from the official view, get the solution up and running immediately by using whatever it takes approach, rapidly evaluate near term needs, and think about the long term needs.

You may want to bookmark this post so that you can find it quickly in the time of need.

Constantin K.
Firebrand Architect®
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...