Monday, March 23, 2009

patterns & practices - Application Architecture Guide 2.0

"This guide provides design-level guidance for the architecture and design of applications built on the .NET Framework. It focuses on the most common types of applications, partitioning application functionality into layers, components, and services, and walks through their key design characteristics.This guide is a collaborative effort between patterns & practices, product teams, and industry experts."

http://www.codeplex.com/AppArchGuide

It's a useful guide, but use with caution. At times the authors confuse the perspective. For example a "tier" is used interchangeably with a "layer." This is not correct since a tier is usually defined to exist in a run time perspective and a layer in a static perspective. All in all a very useful composition.

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

Sunday, March 22, 2009

Complexity in Software Architecture and a new architect role

Things are just getting worse for software architects. Relative stability of business models and computing paradigms of the 2000's has vanished. Making the right early design decisions has become very difficult. Keeping up with technical and operating environment complexity has become nearly impossible.

Humans deal with complexity through abstraction. With rapid growth of complexity in the software architecture domain (both business and technical perspectives) we're now seeing divergence of software architect roles. It's not possible to be a great security architect, a great performance architect, and a great general software architect at the same time. Recently architects have been specializing, often not by choice, to fit the business domains and their operating environments.

The important point is that a new breed of architect role needs to be officially recognized. It may be called a composer, orchestrator, manager, or a solution architect. In this role an architect would only be responsible for creating and maintaining the conceptual integrity of a solution. The conceptual integrity then needs to be maintained and managed in light of changing environment (new constraints, funding, requirements, policy, staff). This architect role would be responsible for making the right timely decisions as to when to bring in appropriate experts. Some may argue that this role exists now and it's the role of a software architect, but it's not possible for a single person to orchestrate the activities of other specialists and be responsible for technical structure of the whole solution.

Over the past few years ( 2006 - 2009) a new trend has developed where more and more architects specialize in a specific area of quality attributes (e.g. security, performance, usability) and relive themselves of duty of the end-to-end solution ownership. There is no question that specialization is necessary to gain the appropriate level of technical depth to be effective, but who is left to be responsible for the conceptual integrity of a solution? Often this role is filled by someone who doesn't understand how specialists work together and how they must be integrated together. Yet this is a very important role, because in order for specialists to be effective their input must be appropriately timed. For example, when was the last time security was effectively retrofitted into an already existing solution? An orchestrating architect needs to recognize the need for a security specialist and then figure out when to incorporate that expertise into the project.

This orchestrator role doesn't explicitly exists because organizations expect professionals to be either technical software architects (sometimes listed as senior software engineers in job advertisements) or project managers. The recognition for something in between doesn't exist.

Successful projects have someone who maintains the end-to-end perspective. It's a challenging role as a person doing this is likely doing this along a set of other major responsibilities.

As the complexity of our computational environments and the complexity of business solutions has expanded we need realize that in order for software architecture specialists to be effective their work needs to be thoughtfully orchestrated by someone who has time, resources, and authority to create and maintain the end-to-end conceptual integrity of a software solution.

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

Wednesday, March 18, 2009

Fifth SEI Architecture Technology User Network Conference (SATURN 2009)

I "subscribe" to the general principles of the Software Engineering Institute's (SEI) software architecture paradigm. I apply various aspects of the approach in my day to day activities. If you're a fan of the SEI's work on software architecture you should consider going to their annual conference (May 4 - 7, 2009) to mingle with likeminded colleauges. Early bird registration is through March 31st. A 10% off coupon may be available if you're interested.

Link to the conference site.

Constantin K.
Firebrand Architect®
SoftwareArchitectures.com

Monday, March 16, 2009

Analysis paralysis

Analysis paralysis is a common problem in the software requirements domain. Engineers or requirements analysts become overwhelmed with amount of information and get bogged down in details.

Software architects face a similar problem. If an architects seeks perfection or the best solution for a given problem he or she may get bogged down in the details of various design alternatives. A more effective approach is to invest time in understanding the key architectural drivers - the requirements that have a profound effect on architecture (i.e. critical functional requirements, quality attributes, and constraints). By quantifying your requirements (e.g. by using quality attribute scenarios) an architect will be able guide your decision making process through various design alternatives.

As Fred Brooks said - getting the conceptual integrity right is the most difficult, but the most important part of your job. To help you with this process you should use an iterative approach to developing architecture and participate early and vigorously in the requirements elicitation and analysis phase.

Let the properly stated requirements shape your architecture and let the architecture shape your requirements.

Constantin K.
Firebrand Architect®
SoftwareArchitectures.com

Sunday, March 15, 2009

The role of organizational politics in Software Engineering and Software Architecture design

This is a very important topic I've been examining for a number of years. While my Ph.D. work on "the cost of organizational politics on software engineering" is many years away it's important to raise the awareness of this subject matter.

The topic of organizational politics is not new. The concept surfaced in 1958 and in early 1980's the topic was actively studied and analyzed. There is no definitive guidance since it's a challenging topic to study; after all this is about the behavior of people. There are many factors that shape the game of politics: individual values and ethics, organization's structure and the way of life (e.g. "cooking books"), environmental conditions (e.g. market stress), and performance reward criteria (e.g. measuring and rewarding the wrong results). What's clear from research is that there is a distinction between an actual political behavior and a perception of a political behavior. For a software architect it's important to recognize and manage both.

Design choices in software architecture are often based on experience and human factors, but architects often don't recognize this. It's natural since most software architects came from the trenches of software development where programming activities are closer to the actual implementation and hence more structured.

Some questions to consider:
- Does your organization openly recognize design constraints? E.g. organization has made a commitment to J2EE platform for solutions of type X.
- Is the effort of analyzing design alternatives, if exists, seriously considered when a design approach is selected?
- Are you aware how you personally avoid, reduce, or promote organizational politics? Not all politics are detrimental. The political game can be played to promote the goodness of software architecture design and implementation process.

It's good to admit that politics play a role in the design process. Actually it's healthy to admit so as it shows maturity of an organization or a team / person.

Remember that you as an architect make conscious and unconscious decisions in your day to day activities that may be perceived by others as political decisions. To protect yourself from unintentional consequences be sure that your personal priorities do not become your team's agenda, else the team chemistry is going to change and you're not going to like the result.

Constantin K.
Firebrand Architect®
SoftwareArchitectures.com

Saturday, March 14, 2009

Insights from vendor panel on Cloud Computing (FOSE 2009)

The leading providers of Cloud Computing services (IBM, Microsoft, Google, and Amazon ) gathered for a panel discussion at FOSE 2009 organized by Booz Allen Hamilton.

Observations:
- Standards have matured significantly over the past few years for both Software as a Service and Infrastructure as a Service.
- Significant gains have been made with respect to interoperability, but until vendors develop a usable way to collaborate adoption will be difficult.
- Trust will make or break clouds. Security is still a big issue - IPv6 will help.
- Private clouds are likely to come first before commercial clouds become widely used.
- A cloud provides substantial benefits when economy of scale is reached.
- Any organization considering cloud computing needs to develop and understand its total cost of ownership (TCO). Cost standards are not mature.
- Cloud Computing is not SOA.
- Cloud Computing maturity level models are being developed (Booz Allen).
- Demand for Cloud Computing has been established - there is a substantial market for the services.

Cloud Computing is becoming a viable option for mainstream software solutions. What does this mean for a software architect? More design options, new design patterns, and greater solution flexibility. Cloud Computing will require substantial investment in education and experimentation in order to understand its limits and applicability to your business solutions.

Constantin K.
Firebrand Architect®
SoftwareArchitectures.com

Friday, March 13, 2009

Cloud Computing Wargames at FOSE 2009

Booz Allen Hamilton held Cloud Computing Wargaming sessions at FOSE 2009 (March 10 - 12th 2009). This wargame simulates the thinking process and the choices IT decision makers have to make in real world as they develop organization's capabilities to meet business or mission challenges. The goal of the exercise is to get the players thinking about the tradeoffs between different computing resources, associated costs, risks, and resulting benefits.

Cloud Computing is not a new concept, but with rapid progress of standards and maturity of technologies "on demand" computing has become a viable option for many organizations.

During the 90 minute session a table competes against six other tables. The goal of the game is to collect Mission Value Points (MVPs). A team obtains MVPs upon successful completion of tasks. To complete a task a team must build a set of capabilities required to support a task. A capability can be built in "Traditional IT", "Hybrid Cloud", or "Commercial Cloud". Over the course of the game a team builds up a portfolio of tasks it has to support. Upon completion of each turn if a given task has been successfully supported with existing capabilities, then a team gets an established number of MVPs for that task.

Players quick realize that in "Traditional IT" computing environment the invested resources cannot be rapidly re-allocated to meet challenges of new tasks. Moreover additional human resources are necessary to support "Traditional IT." Cloud Computing is not a cheap option and there is a resource barrier if a team chose to build their own cloud. Similarly with the "Commercial Cloud" a team would loose invested money and have less control of the services available through that offering.


Watch Booz Allen Principal Rod Fontecilla comment on the essence of the game. Lessons learned from a croupier's perspective in a future post.
<a href="http://video.msn.com/?mkt=en-US&playlist=videoByUuids:uuids:25029772-6d0f-4ce5-809e-280bd49f9db5&showPlaylist=true&from=msnvideo" target="_new" title="War Games">Video: War Games</a>

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