Gabriel Morgan : Architect Skills

Inappropriately comparing Building Architecture and Software Architecture

Gabriel Morgan — Tue, 03 Mar 2009 06:30:00 GMT

Mike Walker wrote a great little article describing that it is largely inappropriate to compare Software Architecture and Building Architecture professions - see here. I think Mike has a great point that the two types of architecture disciplines are so different that it's hard to rationally compare the two.

Mike's blog reminded me my wife's comments on article titled "If building architects had to work like IT architects" written a couple of years ago. By the way, my wife is a commercial and residential Building Architect. Anyway, in that article, Katheryn felt it inappropriately assumed similarities of Software Architecture and Building Architecture to the point she felt compelled to comment and help explain that the article's author is probably not too knowledgeable of the Building Architecture profession.

Note: Although I feel it is largely inappropriate to compare the two professions, I wish we could. Unfortunately, as Mike points out, Software Architecture is just way too immature a profession at the moment.

Here's a repost of my wife's comments to the "If building architects had to work like IT architects" article. Katheryn Morgan wrote:

"The article is misleading because your IT projects are better related to a commercial non- personal project. Your clients would be equivalent to a developer not an individual looking for a personal residence. It can be done different ways, but this way is very common:

Initial Design

If the client is really unsure of what he wants and only has a vague idea and he wants to see some ideas first then he is paying for the head designer's experience. The team is made up of different experienced architects and workers. Each person's time is charged to the client at a different rate. Just like consulting, we have to assign our time to each project. The head designer would charge more per hour than the person assigned to draw it up. The more re-draws based on the clients wishy-washy-ness the more money they are being charged. The client is charged for mileage for site visitations, city department visits etc. Once a design has been agreed on (the project can easily be, and often does get nixed because the client has not acquired the site for the project or the investors have backed out or there are problems with the city allowing such project etc. You can convert any of these problems into your IT world I'm sure) then there is a next phase of costs.

Documentation Phase

The client will be charged by how many sheets of documentation is required for the project to go to a contractor to get sufficient bids for cost of construction. The lead architect by experience should know how many sheets would be required based on the size of the project. The client is also charged for all printing and mailing costs.

Construction Documentation Bidding

The documents are sent to several prospective contractors chosen by the architects and sometime by the clients, as they have probably worked with some before and others chosen because of their direct experience with this particular type of project. The builders bid this project on the hopes they will receive the project and no money is charged by them. The winner is the one who comes back with the best realistic construction cost and can generally show a realistic construction time line with milestones that they are held accountable for and they receive partial payments as long as those milestones are reached. There can also be a bonus incentive for them to finish on time (which rarely happens). This process is kept in strict confidence and the architect never reveals to the other builders what the others bid was.

Construction

Here is a key point different to your world: the designers and the constructors (builders) are different entities. The architect’s role here is to see to the client’s BEST interest. the architects answers RFI's and does site visits to ensure the vision of the project is coming to fruition. The architect answers requests for payment by checking if the milestones have been met, reporting progress to the clients and if the client is satisfied he will approve payment, and the architect will pay the builder.
At the end of the project the architect does a walk thru with the client and builder and any things that need fixing are written and given to the builder. He has to finish these last things before a certificate of occupancy is issued and the builder is given his last payment and any incentive bonus. The architect is also in charge of getting all permits from the city and any official requirements so the client can easily transition."

Enterprise Solution Architects and Leadership

Gabriel Morgan — Sun, 18 Jan 2009 02:18:00 GMT

I strongly believe that Leadership is a critical competency for successful Enterprise Solution Architects. To some, that statement may seem bold. To others, its obvious. for those that this seems bold, I hope this blog post helps explain why Enterprise Solution Architects have strong Leadership competencies. For those that this statement seems obvious, I'm simply attempting to refine this concept to bring it to a more mature level.

A bit of my background leading to thoughts on strengthening Leadership competencies as an Enterprise Solution Architect

During my career as an IT guy, I've always been laser focused on my career mission "Improve IT's business value proposition". This is my passion and it is my guiding principle for making career choices. It's worked well for me probably because there always seems to be new opportunities to explore and deliver more business value such as; exploring different software delivery models, exploring different software design processes and techniques, implementing new and exciting technologies, engineering business architecture, and scaling to enterprise-level constructs like enterprise architecture frameworks and organizational dynamics. In fact, I feel lucky to have been able to achieve so much and still be totally inspired to learn and grow more.

My career has taken me through many IT roles gaining experience as an IT software engineer, tester, business analyst, project/program manager, and solution architect. I've carried pagers while in IT operations support roles. I've spent time in sales selling software solutions and I've spent time as a consultant delivering software solutions and coaching customers and partners how to deliver software solutions. Because I've always had a hankering to make bigger, broader, enterprise-wide business value from IT, my career has led me to where I sit today, an Enterprise Solution Architect.

Enterprise Solution Architects require Leadership skills the most

I think that all Architects require Leadership competencies to some degree but one Architect type that stands out as being the most dependent on Leadership is the Enterprise Solution Architect. Because I haven't seen an attempt to articulate the Leadership abilities in the context of the Enterprise Solution Architect role, I thought I'd share my opinion of what they might be.

So, here's how I think of Leadership. Leadership is a competency and it can be decomposed in a number of ways; leadership principles, habits, values, emotional intelligence abilities, leadership imperatives, frameworks, competencies, et al. All are valid and often share the same semantic meaning but conveyed in different terms and constructs giving us lots of choices to find the one that resonates with each of us individually.

Daniel Goleman's Leadership model as the base construct

One such Leadership model that resonates with me is Daniel Goleman's Emotional Intelligence (EI) abilities organized by the domains Self-Awareness, Self-Management, Social Awareness and Relationship Management. The complete list of Goleman's EI abilities with definitions are located at the end of this blog.

This is an Architect's blog post, so I created some views of the EI domain model as well as the actual model using UML notation for those who like to read models:

Leadership Domain Model

Leadership Object Model

Relating Goleman's Leadership Competencies to the Enterprise Solution Architect

So, how does this all relate to the Enterprise Solution Architect role you say? Well, I think that this is where things get fascinating. Below is an attempt to describe how Goleman's Leadership abilities relate to the Enterprise Solution Architect role. It is very rough but my hope is to mature the thinking to the point we can manage Leadership abilities like we can with other Architect skills like I described in this blog post regarding growing Solution Architects.

It should be noted that the Enterprise Solution Architect's Leadership competencies are required or be the highest maturity achievable. The aim of this blog post is simply to describe the relationship between Leadership competencies and the Enterprise Solution Architect role.

Leadership Competency	Narrative description how Enterprise Solution Architects use the Leadership Competency
Self-Awareness
Emotional self-awareness	This is one of the more critical competencies that Enterprise Solution Architects have. We are often engaged in discussions that are extremely complex with very senior leaders when suggestions are asserted which unintentionally break the integrity of the enterprise architecture we have so carefully nurtured. Enterprise Solution Architects must have self-awareness competency to inject architectural integrity back into the discussion without sacrificing relationships or, as Goleman might say, "emotional capital". Take for example the situation of enterprise planning. There are times when senior leaders suggest major platform consolidation decisions while, unintentionally, grossly oversimplified the engineering rigor involved in defining shared software platforms. Instead of bursting aloud and delivering 'an education' to the group, Enterprise Solution Architects might choose another route. Perhaps s/he might respectfully acknowledge the leadership's role and compliment the suggestion with the option of off-lining that decision to allow time to review impacts and return with their analysis results.
Accurate self-assessment.	Because Enterprise Solution Architects interact at all organization levels in the business and IT organizations, they become acutely aware where they must grow and improve in order to be more effective. The best Enterprise Solutions Architects, therefore, seek mentors and coaches, join networking clubs with a passion for self-improvement. This is one of the reasons why find themselves at networking events and sharing experiences at enterprise architecture conferences.
Self-Management
Self-control	Enterprise Solution Architects are some of the most psychologically mature Architects an organization has. They are often "the rocks" within the most complex, high-profile IT projects a company has. They are masters of self-control for the project team and in planning teams. Their decisions carry weight both in the eyes of the business and IT and any wavering can cause ripple effects strong enough to cause doubt and ultimately shake the foundational confidence of a project.
Transparency	Transparency is a major part for gaining a Trusted Advisor relationship with senior business stakeholders and engineering teams. Often, the Enterprise Solution Architect must deliver messages that are not what stakeholders want to hear so setting expectations early and being transparent to the decision-making stakeholders is critical. Take for example the situation where Enterprise Solution Architects coordinate the support for a shared enterprise-wide software platform. Enterprise Solution Architects must be able to gain support from several Lines of Business and engineering organizations to commit to the software platform. This is a tremendously complicated task that can be thwarted from several angles. Enterprise Solution Architects provide a Leadership role through this process and the great ones build Trusted Advisor relationships through transparency.
Adaptability	Adaptability is a core competence of the Enterprise Solution Architect because of the diverse situations and audiences they are faced with on a daily basis. As an example, I once led a highly complex software design discussion with highly-talented and, should I dare, 'critical' engineers involving system integration modeling of our Microsoft Online Order Management systems in the morning, sat with business leads to brainstorm licensing business logic for our to-be-released Online Products over lunch, and delivered an architectural brief to a group of Business and IT Vice Presidents on the impacts to our enterprise for our S+S company strategy all in the same day.
Achievement	Enterprise Solution Architects are measured by adoption. Everything they are set out to accomplish is carefully prioritized and burned into the forefront of their consciousness. Think of Stephen Covey's second habit of highly effective people "Begin with the End In Mind". The 'end' for an Enterprise Solution Architect is the delivery of change whether it be decisions on which software platforms are to be built and how they are designed, delivery of enterprise-class software solutions, optimization of the application portfolio, enabling IT with the right architect to deliver faster, efficiently and cost-effectively.
Initiative	Enterprise Solution Architects have the opportunity to view broadly across the company and often are quick to see opportunities for progressing the advancement of the enterprise architecture. They look for ways to gain adoption quickly and often are able to provide feedback to IT process owners or organization designers on observations made that potentially can improve the organizational effectiveness in terms of improved delivery to the business.
Optimism	Enterprise Solution Architects know that no one want's to work with pessimistic wet blanket. Gaining momentum is critical to the success of delivering large-scale initiatives and, therefore, optimistic leaders help carry the momentum. Not all Architects can perform the Enterprise Solution Architect role. It is mostly a thankless job and often highly criticized. I'm sorry if this sounds like a bleak picture for the Enterprise Architect but to be honest, we must be optimistic to try, try again.
Social Awareness
Empathy	I just love this Leadership ability because it is often so sorely lacking in the IT industry, thus representing a great opportunity to apply focus and get huge improvements. Engineers often don't have the training or basic social skills to have a positive dialogue. All the more reason why the Enterprise Solution Architect has very mature empathy abilities so as to resonate and get decisions made to rapidly enable change. I can't put it better than Jack Welch's "Three S" approach to Leadership; Self-Confidence, Simple, Speed. I've created a conceptual model of the "Three Ss" concepts and added a couple of new one's taken from anecdotal mentions from Goleman for another View to help describe the concepts. Here's how to relate Empathy to the Three Ss concept. Through Empathy, an Enterprise Solution Architect can identify a Simple message that resonates with others allowing them to act on the message with speed.
Organizational awareness	Enterprise Solution Architects often find themselves in organizations that lack fluid understanding for involving enterprise-wide concerns. This is common and natural. For example, large companies often have several business strategies that are not in-sync eventuating in siloed supporting IT systems. Enterprise Solution Architects must be able to understand who to influence in order to contribute due diligence efforts for deliver solutions to enterprise concerns such as application rationalization, delivery of shared enterprise software platforms, software platform designs built for flexibility, reusability and availability. Now, I would like to make a distinction between Organizational awareness from a Machiavellian politician who studies organizational dynamics and manipulates and drives their self-interests. Like Goleman, Stephen Covey and Jack Welch note often, "those individuals are a bore and bring down organizations." I'm in complete agreement.
Service	Service is one of the most important competencies Enterprise Solution Architects have. We are humble and serve our business partners and teammates to achieve our goal, adoption. I described tips for gaining adoption in a previous blog - see here. Enterprise Solution Architects fill the gaps and complement the team's plan directly or indirectly through encouraging the appropriate role owner to pick it up.
Relationship Management
Inspiration	When Enterprise Solution Architects discover business problems that cross several Lines of Business and engineering teams, they have a tough challenge ahead of them. Often, Enterprise Solution Architects make all groups aware of the problem and inspire them to collaborate on solving the problem together, thus bringing synergy to the organization.
Influence	In the software industry, if you are not directly writing source code you are in an influencer role. I cannot stress the importance Enterprise Solution Architects place on this leadership competency. It is critical to the success of gaining momentum for software initiatives and truly delivering in a Trusted Advisor capacity.
Developing others	Goleman often cites statistics that the IT Business sorely lacks this competency. Goleman believes that this is likely due to the fact that engineers focus on improving one's technical skills rather than focusing on improving other people's skills. He's got a great point. Enterprise Solution Architect's understand that no single role will be responsible for improving IT's value proposition to their business stakeholders. We spend a lot of time growing an organization's competence. The best Enterprise Solution Architects I know, dedicate time to mentor others, contribute to skills discussions and often express their ideas in broad audiences all with the intention of helping grow the discipline in the direction of improving IT's value proposition to the business. In fact, Developing others is why I blog (and I wish I blogged more often), mentor aspiring Architects in and outside of Microsoft and one of the sole reasons I choose to be an Enterprise Solution Architect within Microsoft. With this blog, my hope is that I catch the attention of another Architect to investigate and learn more about leadership competencies and contribute to their growth and success.
Change catalyst	Many esteemed thinkers in the space of Enterprise Architecture often evangelize the role of Enterprise Solution Architects as 'change agents'. This is true. Like I discussed in the Initiative item above, Enterprise Solution Architects do have an unusual position of seeing an impartial view of the 'big picture' and when opportunities for gaining efficiencies regarding re-prioritization of our business needs, tweaking our delivery process, restructuring governance models, identifying skill gaps, to drive change for improving the IT organization's effectiveness to deliver more value to the business, we do it.
Conflict management	I love this competency! In the IT industry there is so much social insecurity that it impairs even the most trivial discussions resulting in relationship destruction. These outcomes are unacceptable to Enterprise Solution Architects and we mitigate these outcomes by leaning heavily on our Conflict Management skills. For example, Enterprise Solution Architects often find themselves facilitating an initiative via a virtual team of multi-discipline resources from all over the organization. Inevitably, there are pitfalls to avoid from insecurities that exist with each of the team members. Normally, insecurities manifest themselves from team members that were part of a failed project they wish to not be reminded of, or senior resources wanting to be recognized for their position by subordinates, or from highly educated individuals who want to be publicly recognized for their educational credentials, or for cultural sensitivities typical in the western and eastern cultures and the list goes on. At the surface, one might say "why do they behave so childish?" and they'd be right if it weren't for the fact that people are very emotionally complex beings - we are not beings from the planet Vulcan where logic prevails over all social conflict. :) Enterprise Solution Architects identify and respect other's underlying personal insecurities, which are often unsaid, and empathize with them in a very non-threatening manner, and usually in private. Then, suggest a simple resolution to the group that a) can progress the group's initiative, and b) does not seem threatening to any one person or the group they represent.
Teamwork and collaboration	Enterprise Solution Architects, by necessity, have experience managing project teams, virtual teams, relationships "owners" with other organizations on behalf of their organization to deliver planning and delivery functions. We often exude the ability to create an environment with strong collaboration and do this by leveraging our Teamwork and Collaboration competency.

Just some closing notes

There is nothing new described in this blog other than an attempt to articulate a relationship between two concepts. It is my interpretation of the fantastic work already delivered by Leadership thought-leaders in the context of the Enterprise Solution Architect role.

Acknowledgements: One of the great pleasures from working at Microsoft is the opportunity to work with unbelievably talented people. One such person is Harry Tucker and a few others whom I'm not sure I have the right to publicly identify...Jeremy, Mike, Chad and Gray. ;) Anyway, much of what I've written below was directly triggered by their coaching and I'm very grateful to have crossed paths with these individuals.

Here are Daniel Goleman's Leadership Competencies:

Self-Awareness

Emotional self-awareness. Leaders high in emotional self-awareness are attuned to their inner signals, recognizing how their feelings affect them and their job performance. They are attuned to their guiding values and can often intuit the best course of action, seeing the big picture in a complex situation. Emotionally self-aware leaders can be candid and authentic, able to speak openly about their emotions or with conviction about their guiding vision.
Accurate self-assessment. Leaders with high self-awareness typically know their limitations and strengths, and exhibit a sense of humor about themselves. They exhibit a gracefulness in learning where they need to improve, and welcome constructive criticism and feedback. Accurate self-assessment lets a leader know when to ask for help and where to focus in cultivating new leadership strengths.

Self-Management

Self-control. Leaders with emotional self-control find ways to manage their disturbing emotions and impulses, and even to channel them in useful ways. A hallmark of self-control is the leader who stays calm and clear-headed under high stress or during a crisis - or who remains unflappable even when confronted by a trying situation.
Transparency. Leaders who are transparent live their values. Transparency - an authentic openness to others about one's feelings, beliefs, and actions - allows integrity. Such leaders openly admit mistakes or faults, and confront unethical behavior in others rather than turn a blind eye.
Adaptability. Leaders who are adaptable can juggle multiple demands without losing their focus or energy, and are comfortable with the inevitable ambiguities of organizational life. Such leaders can be flexible in adapting to new challenges, nimble in adjusting to fluid change, and limber in their thinking in the face of new data or realities.
Achievement. Leaders with strength in achievement have high personal standards that drive them to constantly seek performance improvements - both for themselves and those they lead. They are pragmatic, setting measurable but challenging goals, and are able to calculate risk so that their goals are worthy but attainable. A hallmark of achievement is in continually learning - and teaching - ways to do better.
Initiative. Leaders who have a sense of efficacy - that they have what it takes to control their own destiny - excel in initiative. They seize opportunities - or create them - rather than simply waiting. Such a leader does not hesitate to cut through red tape, or even bend the rules, when necessary to create better possibilities for the future.
Optimism. A leader who is optimistic can roll with the punches, seeing an opportunity rather than a threat in a setback. Such leaders see others positively, expecting the best of them. And their "glass half-full" outlook leads them to expect that changes in the future will be for the better.

Social Awareness

Empathy. Leaders with empathy are able to attune to a wide range of emotional signals, letting them sense the felt, but unspoken, emotions in a person or group. Such leaders listen attentively and can grasp the other person's perspective. Empathy makes a leader able to get along well with people of diverse backgrounds or from other cultures.
Organizational awareness. A leader with a keen social awareness can be politically astute, able to detect crucial social networks and read key power relationships. Such leaders can understand the political forces at work in an organization, as well as the guiding values and unspoken rules that operate among people there.
Service. Leaders high in the service competence foster an emotional climate so that people directly in touch with the customer or client will keep the relationship on the right track. Such leaders monitor customer or client satisfaction carefully to ensure they are getting what they need. They also make themselves available as needed.

Relationship Management

Inspiration. Leaders who inspire both create resonance and move people with a compelling vision or shared mission. Such leaders embody what they ask of others, and are able to articulate a shared mission in a way that inspires others to follow. They offer a sense of common purpose beyond the date-to-day tasks, making work exciting.
Influence. Indicators of a leader's powers of influence range from finding just the right appeal for a given listener to knowing how to build buy-in from key people and a network of support for an initiative. Leaders adept in influence are persuasive and engaging when they address a group.
Developing others. Leaders who are adept at cultivating people's abilities show a genuine interest in those they are helping along, understanding their goals, strengths, and weaknesses. Such leaders can give timely and constructive feedback and are natural mentors or coaches.
Change catalyst. Leaders who can catalyze change are able to recognize the need for the change, challenge the status quo, and champion the new order. They can be strong advocates for the change even in the face of opposition, making the argument for it compellingly. They also find practical ways to overcome barriers to change.
Conflict management. Leaders who manage conflicts best are able to draw out all parties, understand the differing perspectives, and then find a common ideal that everyone can endorse. They surface the conflict, acknowledge the feelings and views of all sides, and then redirect the energy toward a shared ideal.
Teamwork and collaboration. Leaders who are able team players generate an atmosphere of friendly collegiality and are themselves models of respect, helpfulness, and cooperation. They draw others into active, enthusiastic commitment to the collective effort, and build spirit and identity. They spend time forging and cementing close relationships beyond mere work obligations.

Tips for gaining adoption

Gabriel Morgan — Fri, 06 Jun 2008 18:45:00 GMT

I began writing a quick response to Erik’s question in this blog about Architect’s high-order bit is Adoption. Erik asked the question how to get people to adopt ideas and before I knew it I was over a page in my response because it was a lot of fun to answer it so I decided to make the response an individual blog post.

@Erik, fun question and thanks for asking.

Maybe I should respond using the typcial 'carrot' versus the 'stick' approaches. The carrot being an enagement between an Architect and the team that has obvious value to those s/he influences. The 'stick' approach resembles a policy-enforcer.

I've been down both paths and currently think that the carrot is the path of least resistance resulting in greater adoption. So, instead of focusing on the 'stick' approaches, let me talk to you about ideas how to acheive results using the carrot approach.

Disclaimers:

1. I'm not saying that the stick approach cannot be successful. I think that the stick approach requires a lot of organizational and cultural characteristics that finding such an organization with these prerequisites is very difficult.

2. I’m also not assuming it’s an all-or-nothing situation. Clever Architects appropriately use both approaches. I will say that they often lead with the carrot approach.

Ok, now for some tips to help you gain adoption of your idea in no particular order:

1. Gain trusted advisor with the business(es) that drive the project. If you are able to build strong relationships with the business leads that control the description of the business problem, you will be able to:

a. Help them articulate the problem in such a way that

i. It desciribes the area of the solution architecture you are most interested in influencing. There are always times when the business wish to achieve a goal but focus more on areas of the business problem that meet their concerns and detail these needs. What can happen is that the business gloss over areas that are not focus areas of the business problem, leaving a bit of ambiguity or wiggle-room for interpretation that may result in a poor-quality design in the solution.

ii. May implictly suggest how to solve the business problem that naturally includes a particular idea you have about the Solution Architecture. If you are able to have the business clearly describe Business Requirements that layout the need for a high-quality solution design idea you have, you will have the ability to ensure that the solution delivery team explicitly meet these Business Requirements by adopting your design idea.

b. Ask for their support in driving architectural change in the direction you wish. If you find yourself in the position the design team have built a poor design to solve a loosely described Business Requirement, you must be able to articulate the business ramifications of the poorly designed solution in terms of financial risk, Customer experience, Supplier/Partner experience, etc to raise awareness and appreciation of the design. Then, naturally suggest architecture options you have to help solve the problem and work with the business to help drive them through the project team. This can get quite complicated because of the dynamics of the project team. Normally by this time in a project’s lifecycle much of the scope is locked, estimates are done, resources committed, etc so getting these types of changes pushed through will require a very good explaination as well as a good bit of politicking to make sure that the business leads and project leads support your idea.

2. Contribute to the design of a project’s lifecycle process. I don’t necessarily mean that you are a part of the lifecycle process therefore someone who requires sign-off before a team can continue. Being a Sign-Off Owner is always fraught with pain and I don’t suggest this approach - it normally falls in the ‘stick’ approach and I prefer to stay away from this. What I am saying is to help the team build a project lifecycle process derived from your favourite methodology/technique/framework like Microsoft Solutions Framework (my personal favourite). Ensuring the team adopts the process that enables them to function together in a complimentary fashion is huge value to you. In fact, I believe that getting the team to function together is onf of an Architect’s prime directives. Help the team to be able to easily declare when an individual is out-of-role or is not performing their function. When you have an idea that you wish to be adopted, you can rely on the project's process model and team model to gain adoption. If a team isn’t functioning correctly, any silverback/alpha-dog personality can bypass any process and ignore you and your idea…or anyone elses for that matter. Very Bad.

3. Steward the models. Let’s face it, he who maintains the minutes writes the facts. All projects will require some sort of documentation. The key is to offer up skills and resources to help document it and, coincidentally all the way, you get the opportunity to suggest how documentation might be done to a) have consistency in the documentation and b) communicate it. Offer to take the burden of managing the model repository and be the modeler for the documentation. This is a really powerful technique to gain adoption of your ideas because as model-monkey, you:

a. Are invited to most meetings to document the discussion so you are well-informed and are present to help influence decisions.

b. When documenting via modeling, you gain integrity in the documentation via integrity of the models. This assumes you are using a proper modeling tool not what I call a ‘picture tool’. You get to spot poorly written requirements ad designs and articulate them via the model. This helps prove the value of the models and your role to steward them.

c. Caveats with this technque. If the modeling tool doesn’t allow for the models to be easily accessible and easy to use then you run a very big risk in the models not being used or referenced. When this happens, you also lose credibility and diminish your trusted advisor position. Be very careful when and how you apply modeling tools.

4. The Architects Middle-out Strategy. Ok, maybe mangling the term ‘middle-out’ too much here J. What I mean is to start with the Leads and work out from there. Avoid top-down and bottom-up, that is, Executive-down and Individual Contributer(IC)-up respectively. Gain trusted advisor for the managers with accountability that do the actual work in the area you wish to change and they will help you manage-up and manage-down. They are often the ones making the decisions that inform executives. They are also the ones who delgate the work to ICs. Partnering with these folks is critical.

5. Be selfless NOT selfish. We all have vision and ideas to be adopted. The key for an Architect is to find a way to make your vision and ideas resonate with whomever you want to influence. Don’t presume they care about your vision and ideas. Don’t presume they will explicitly understand them and the value they bring to the enterprise, customer, partner or shareholder. Seriously, this is super important. Always focus on helping them solve their problem. Then, along the way, interlace your ideas with the solution. This goes for efforts that are in planning, execution or maintaining situations. For example, even if your idea is as extreme as stopping an initiative, work with the planning team to understand their motives and goals and then cleverly help them discover your idea and collectively agree that it is in the best interest of the company to stop the initiative. Architecture is, and should be in my opinion, a thankless job. We are about doing the right thing which often means getting others to be successful and having their success recognized. Get used to it J. If, as an architect, you’re keen to be recognized or be ‘in the media’ as often as possible for driving change, you will dissapointed and often.

6. Understand and articulate your value proposition. Have a crystal clear value proposition to every project team lead and every senior manager of those team leads. I have a rule of thumb for describing value of a role. If you can’t explain the value proposition in 10 words or less and the meaning has obvious value to ALL of the project team leads, you are doomed. For example, here are some basic value propositions which resonate with all leads:

a. Project/Program Manager: Ensure the project is on-time and on-budget.

b. Testing Team Lead: Prove the solution works

c. Development Team Lead. Build the solution.

d. Release Manager. Deploy the solution.

e. User Experience. Ensure the solution is usable.

f. Architect: Ensure the quality of the solution to its stakeholders. This is what I often use, and is an extension of MSF’s definition. It is a bit squishy but good enough in my experience. When people question, what I mean by quality I answer based on their role. For example:

i. For Project/Program Managers, it is the traceability of the business problem to the solution to ensure no wasted efforts and to make sure we are solving the business problem and that the solution nicely fits within the enterprise environment in which it will be deployed.

ii. For Testing, it is the explicit focus on the solution architecture to optimize system quality attributes (Performance, Security, Flexibility, etc) that they must also test for in addition to the obvious Functional Testing.

iii. For Development, it is the explicit focus on the solution architect to optimize system quality attributes to meet the needs of the business owners and IT system admins as well as align to the long-term direction of system integration needs of the shared enterprise systems.

iv. Etc

7. Daily Build. This tip applies the Daily Build principle from MSF. In this context, I mean publish models and diagrams every day allowing you to get your latest thinking out for others to use (i.e. adopt) and provide feedback. You will gain a number of advantages such as:

a. Heartbeat. Your architecture diagrams will show life through a regular publishing and increase your chances of being seen by other groups used improving expectations that you deliver quickly and regularly.

b. Accuracy. By building every day you iterate on the architecture and include the latest impacts of deliverables from other groups such as scope changes, technology choices and involved user groups.

c. Avoid the ‘Big Bang’. You do not want to fall into the trap of waiting for the all requirements or all technology decisions or all whatever to be made. There will always be changes in the things necessary to build the solution architecture. By the time all of these decisions are made the solution will already be done and your ideas for adoption are moot.

This is a good start to the list. I’m keen to collect other tips to add to this blog. If you want to add one, please comment and I’ll post it to this blog.

SWABOK, Archipedia, Uber Architecture Framework, xyz?

Gabriel Morgan — Tue, 09 Oct 2007 19:41:00 GMT

Nick Malik wrote blog post "The culture of art vs. the culture of engineering" that described the problem of architects and developers being caught up in invention rather than reusing software system definitions and concepts.

I wholeheartedly agree with Nick. We’ve all struggled with this problem it seems. The situation I observe is when I point Architects and Dev Leads to reference material with the intention of pointing them to reusable content (albeit a design pattern, a design process, reference architecture, reference model, or a theoretical concept), 9 times out of 10 they don’t readily see what it is I meant for them to learn from it. Btw, by learn I mean; a) becoming aware, b) gaining an understanding and b) applying what was understood. A lot of this is dependent on me not being able to convey a message clearly but much of it depends on the recipient not understanding the purpose and context of the problem they have nor being familiar with the material out there to see how the material can help.

Reusing architectural references is not as easy as pointing people to a published copy of documentation. It often involves a lot of handholding and a bit of luck. Only when there is a fully complete, prescriptive methodology to follow that surrounds the nugget of knowledge I find important, do most feel comfortable.

It is rather confusing, let's face it. There are plenty of proprietary and public concepts, frameworks, processes, models and other material that covers bits of the overall knowledge a senior software system architect needs. The problem is that in the nascent world of software system architecture, there simply is no such thing as the uber methodology that explains how it all fits together and be used for all software system architecture planning, designing, building and operation activities from the Enterprise Architecture to Solution Delivery to Operations Support points of view. To top it all off, when a new good idea comes into the fray (eg SOA, ESB, MDM, S+S, System Quality), rarely do people understand how it fits into the overall software system architecture picture. The result is building yet another methodology, process, framework, etc and the opportunity for old concepts to be renamed and tagged as being 'new'. Confusion compounds.

There have been attempts in the scope of software engineering such as the Software Engineering Book of Knowledge (SWEBOK) found here http://www.swebok.org/. This is an interesting attempt at building the uber reference for software engineering. I wonder if we could build on top of or expand SWEBOK to include all software system architecture stuff and reuse SWEBOK to form a Software Architecture Book of Knowledge (SWABOK). Essentially, it would be a place that hosts best practices that is anchored to an information metamodel to help connect them together and help readers navigate between the references in a structured, hierarchical model.

Alternatively, we could build a site structured on the encyclopedia metaphor - sort of like Archipedia that is a wiki-format software system architecture site that hosts all best practices and links them together. This approach is a little less intentional and a bit more open but maybe the right path to take.

Or, maybe we need to go down the path of building another framework or methodology. But instead of inventing a new concept we invent only what we have to and then point to best practices already out there. This would give us the opportunity to build out a comprehensive and prescriptive framework including team model, process model, and risk management, templates, and examples. Of course, this would require a lot more work and a tighter community to ensure consistency.

It very well could be we need a combination of all of the above at varying levels of depth. I don't really know the answer but am interested to hear from others that have an opinion.

Adoption, rather than Architecture, is the high order bit for Architects

Gabriel Morgan — Wed, 26 Sep 2007 21:21:00 GMT

Over the years I've noticed a strange phenomenon, sometimes the most logical decision isn't the decision made. Have you ever witnessed an unbelievably strong argument to build system infrastructure with all the right scientifically backed architecture documentation, ROI analysis, market analysis and compelling innovation forecasts only for it to be rejected? I have and wonder, why does this happen?

Other than times when an organization simply cannot justify the funds for the right project, there are other reasons for dismissing a sound, scientifically justified system architecture proposal such as:

Organization alignment challenges are too great. For example, there are times when in order to build the proposed system architecture, organizations must collaborate with each other and this is percieved as an unwelcomed challenge. Think of the situation of building a 'core' system to be used by two or more different organizations, the organizations must collaborate on using them and understand the tradeoffs for sharing a central system. This can often result in a "I'm too different" or "I don't want to take on dependencies" excuse from the organizations involved.
Not enough politicking or evangelism. I've seen individuals present and gain momentum for projects which deliver lesser value than others...and win. In sales, we call them "spin doctors". They are masters of influence and can get people chanting and believing a simple message without any sound justification.

We've all heard that an Enterprise Architect is a 'change agent'. I go one step further, all Architects are change agents. Let me give you an example, a project Solution Architect's responsibility is to ensure the software quality of the software the project delivers. They constantly influence the project team to build the right software solution that meets the needs of the key stakeholders as well as ensure the the longevity of the software. An Enterprise Architect is responsible for understanding the business' needs and influencing that the right projects are delivered and they have the right level of system quality.

The point I'd like to raise in this blog posting is that simply building architecture documents, whether it be fully fleshed or not, isn't the high order bit for an Architect. Adoption is the high order bit for Architects. Yes, I'm saying that the engineering aspects of an architect's role is not as important as the abilities to gain adoption of their ideas with the sole purpose of making change - the type of change that ensures the business gets the most value from their investment. Of course, if sound engineering is necessary to make change, then the Architect should do this...but only after careful analysis that this is the right thing to spend time on to actually make change.

I'm not saying that an Architect need not worry or spend time on building sound architecture. On the contrary, if an Architect doesn't do this, then I question the integrity of their ideas. What I'm highlighting is to not depend on sound architecture alone to impact change.

Interestingly, in order to gain adoption and make change, Architects must be leaders. Why? Because leaders are influential, leaders gain momentum, and most importantly leaders consciously understand when to lose and win the right battles in order to with the war. And the war Architects engage on is change.

To my fellow Architects out there, remember not to get stuck on engineering excellence. Architects are leaders and we use these leadership skills to obtain adoption and drive change with the sole purpose of ensuring that the business gets the most value from their investment.

Enterprise Architect vs Solution Architect

Gabriel Morgan — Sun, 02 Sep 2007 19:18:00 GMT

What exactly is an Enterprise Architect versus a Solution Architect? I'd like to chat about the difference because I'm not confident everyone understands this well.

It's actually quite simple. I propose that a Solution Architect is a project team role that is responsible for the system quality of the solution being delivered to the business. I also propose that an Enterprise Architect is a planning role that is responsible for identifying the future state of an organization's IT environment and engage wherever and whomever necessary to help guide project team's to deliver toward it. There are formal definitions out there but I thought I'd simplify it for the purposes of this blog post.

I get the impression there are people out there that think an Enterprise Architect is a Solution Architect but work in enterprise organizations. I also have the impression that there are people out there that think an Enterprise Architect is someone who only works with Powerpoint, collects information from Solution Architects and spends the majority of their time with the business leads and governance boards merely reporting on the information they've pulled together. Although I recognize that there are organizations in situations that implement Enterprise Architect and Solution Architect like this, I beleive they are inneficient and are likely in a transition state to the more efficient role definitions I proposed earlier.

Taking my proposed definitions, I'd like to identify architect subtypes to help support the difference between them to help describe what I'm talking about.

A Solution Architect may have a number of different types of architects working for him/her to help accomplish their task for delivering a high quality solution. For example, s/he might have an Infrastructure Architect to manage the architecture of the solution's hardware configuration so that the solution meets the Quality of Service business and IT requirements while at the same time represents the optimum way to deploy the solution into the target production environments.

There also might be a need for 'specialist' architects depending on the complexities of the business requirements or the target production environment. Such 'specialist' architects usually are called Domain Architects and examples include; Security Architect, Technology Architect (ie architects that specialize in a specific product or technology), Vertical Architects (ie architects that specialize in systems that are specialized in particular industry verticals such as Financial Services Industry, Telecommunicaitons, Public Sector, etc).

An Enterprise Architect may have also have a number of different types of architects in order to piece together a coherent, actionable future state architecture which can easily map to business strategy, be consumed by project teams and be a major contribution in governance activities.

For example, an Enterprise Architect may have Business Architects which document Business Strategies, Business Capabilities, Business Processes and Roles as well as a number of other artifacts to help analyze them such as mapping artifacts (see here).

An Enterprise Architect may also have Information Architects who document the information models such as Data Subject Areas, Data Facets, Business Objects, Business Entities and Data Entities with the intention of supporting the Business Processes while at the same time desiging for data integrity and data quality for the enterprise.

An Enterprise Architect may also have Infrastructure Architects (aka Technology Architects) that focus on the hardware and operating system-level infrastructure.

Lastly, an Enterprise Architect may also have Solution Architects (aka Enterprise Solution Architects and Enterprise Application Architects) who focus on pulling all of the other Enterprise Architecture information together to shape the future state application system architecture.

Here is one place where I think there is confusion by many. You see, I described a Solution Architect at the project-level and an Enterprise Solution Architect across the enterprise and both share the words 'Solution Architect' in their role. They have VERY different purposes but are very complimentary. Could it be that simple of a reason why confustion exists? It just might be.

An Enterprise Solution Architect and project Solution Architect roles are very complimentary and because this relationship is of particular interest to me I'd like to take a moment and propose how they are to work together.

I propose that the Enterprise Solution Architect be involved at the earliest point a new business initiative is created and do very high-level 'solutioning' via whiteboard and reference to future state architecture elements. Then, when the business initiative gains momentum is backed by Enterprise Architecture future state analysis the core project team is formed and the project Solution Architect takes over to be responsible for the solution. The Enterprise Solution Architect becomes a member of the project Solution Architects team and is responsible for the system integration architecture where the solution requires integration between enterprise systems as well as be responsible to provide future state system architecture guidance to help the project Solution Architect make decisions on which systems to commit to using in the solution. The Enterprise Solution Architect then is involved in governance boards to inform decision-makers with future-state architecture artifacts to help justify major technology, system, or business value decisions. Thats it.

As a quick summary, project Solution Architects and Enterprise Architects are different in that they have very different purposes. They are highly complimentary in that Solution Architects focus on delivery of solutions and Enterprise Architects focus on supporting them by documenting future state, participating on their teams and being involved in governance activities.

Skills from different experiences - Well rounded is King

Gabriel Morgan — Fri, 31 Aug 2007 23:54:00 GMT

I currently sit in Microsoft IT and get to share experiences and learn with some of the most interesting folks in the world. My role encourages me to generate good ideas for the company and work with others through natural alignment to build great products for Microsoft. This is good fun.

I'm recently noticing more and more that the soft skills that I've picked up during my career are invaluable to be successful. And for this reason, I've personally begun a journey to strengthen my leadership abilities. One method I use is to look introspectively at myself to discover strenghts to leverage and weaknesses to manage. As a byproduct, I also do a bit of analysis of others around me to find their strengths to leverage and weaknesses to manage. This is what has brought me to this blog entry on the need for well-rounded skills.

My consulting experience: When I was an IT consultant playing roles such as Sollution Architect, Devleopment Lead and Program Lead I was measured on delivering IT solutions to customers that were of highly successful (ie on-time, on-budget, meeting customers satisfaction and of high system quality). In that environment, I learned that it was essential to pick up skills to survive because I was surrounded with folk that had brilliant customer-facing, fast-learning, quality-focused, and most of all strong professionalism skills. You had to have these skills to be successful.

My sales experience: When I was seconded to a sales team for a while as a Enterprise Solution Architect playing roles such as pre-sales technical architect, pre-sales strategist and partner strategy consultant I was measured on driving programs which lead to increased revenue and partner satisfaction. In that environment, I was surrounded with fast-talkers, extremely confident and capable sales resources - I'm not talking the sort that do more adminstrative sales but those few, rare breeds that have mastered the art of executive sales for large enterprise customers.

My IT experience: Over my cumulative IT experience, I have played roles such as Developer, Developer Lead, Test Lead, Program Manager, Solution Architect and Enterprise Architect. All of these roles generally are about delivering solutions to the business. I've been surrounded with individuals who have extensive engineering knowledge and great solution delivery skills. These are essential to be successful delivering IT solutions to the business.

Ok, now the interesting part of this blog. Having a varied background in roles ranging from sales to consulting to IT have really helped me make greater impact. Skills that were a prerequisite for success in one environment are a bonus in another. For example, in IT, skills that I developed while in sales roles that helped me build trust with partners becomes a bonus for learning how to build trust with like-minded groups in IT. And as a result, together we achieve greater impact that is relatively unusual. We acheive a sort of 1+1=3 situation. This is not all that common in IT shops but is normal in sales and consulting.

Let me dive a bit deeper to explain. The stereotypical sales role will require to peice together bits and bobs of products a and b, then peice together a partnership with hardwar vendor x, software vendor y and delivery partner z all within a matter of days. The skills necessary to do this are either there are aren't and if they aren't, you are not as successful a salesperson or presales consultant as one could.

The stereotypical IT roles will require to think long and hard about a software system and then snap to a relatively well-defined team model in a well-defined process model as part of a software development lifecycle for example.

Therefore, one might argue that there are skills developed in a sales environment that could prove useful to other environments such as IT. As products of our environment, we naturally develop the survival skills our environment requires. If we have a relatively well-rounded experience, we have relatively more skills to bring to the table that will allow us to make bigger impact.

Perhaps, if we made deliberate movements to be in positions of different environments and while there carefully nurtured and honed to excellence the necessary skills to survive in those environments we would be all that more effective. I think that this is an interesting opportunity for all of us.

Solution Architect Skills Assessment Idea

Gabriel Morgan — Fri, 20 Oct 2006 19:57:00 GMT

I’d like to talk about another idea I have for improving system architecture which is growing Solution Architects. I believe that one of the primary value propositions of an architect is to mentor and transfer knowledge from their architecture experience to the less experienced. I’ve observed that self-proclaimed architects tend to pull from their background such as software/hardware/mechanical engineering, business analysis, packaged software implementers/configurators, even project management! Not too surprisingly there is a significant bias to what these individuals feel are required skills for Solution Architect. I’m not all that confident that there is a right and wrong skills set for the generic Solution Architect, but I wonder if there is a set of core skills that an architect should obtain before acquiring the title Solution Architect to mitigate poor solutions as well as confusion from those around him/her.

I admit, what has triggered this entry is a result of trying to quantify what a Solution Architects is as a result of meeting countless imposters and witnessing their countless system design blunders. It appears that there is no accepted, industry-wide standard skill set that a Solution Architect must have and I see this as a need that must be filled…so I’ll invent one. Here is an approach a fellow colleague and I have come up with which I’d like to throw out to see if it might be interesting to the Architect Community.

The Approach: I used to perform skills assessments while a technical consultant to measure an individual’s skills for a particular project. The result of the skills assessment was a gap analysis which I would use to contribute to a Readiness Plan that would be used to ramp up the technical team for a large project. This approach has worked well for me and mitigated poor system design and solution delivery risks early in the project lifecycle. I’ve taken this concept and applied to produce a development plan for those wanting to become a Solution Architect. The high-level process we’ve come up with to date goes something like this:

1. Build Skills List for a Solution Architect

2. Have an experienced Solution Architect assign the maturity an individual would require for each skill such as:

a. Value Description

b. 0 0 Non Existent. This skill does not currently exist.

c. 1 1 Weak. This skill exists but not able to work independently without assistance

d. 2 2 Moderate. Good skills exist but requires periodic assistance.

e. 3 3 Strong. Highly capable, this person is often sought after to assist others.

3. Have an experienced Solution Architect interview a candidate and assign a value based on the same value table above to as accurately as possible determine the candidates ability for each skill in the Skills List

4. Calculate the skills gap for each skill of the candidate

5. Stack rank the sills based on the skills gap in descending order

6. For each skill that requires maturing, have the experienced Solution Architect list prescriptive recommended guidance describing what the candidate should consider for improving that skill

7. Have the candidate then assign a priority for each skill requiring maturing based on skill gap and the estimated effort to mature the skill

8. Build the candidate’s development plan using the guidance from the experienced Solution Architect.

I’ve run this approach past a few colleagues and it seems to be intriguing…at least in theory. I think that the trick is identifying the specific skills and their maturity value. Like I noted above, I don’t know if there is a right or wrong skill set but wonder if the skill set should be maintained by a community of architects. I’ve started such a list based on information from the Microsoft Solution Framework, industry research and my experience. Below is a brief outline of the actual skill assessment document and I are building. We have more on this so if you’re interested please let me know. Also, note that the skills are grouped by MSF team role because we think a Solution Architect must have strong skills in every project team role but is an expert in Solution Architecture.

Program/Project Management

Scope Management

Requirements Gathering

Acceptance Criteria

Roles and Responsibilities

Communications Management

Team Model

Estimating

Inter-team processes

Trade-off Strategy

Commercials

Risk management

Progress Tracking

Project Planning

Solution Architecture

Design Documentation

Entity Relationship Diagrams

Object Oriented Design Patterns

Workflow

Design Skills

Design and Develop for Performance

Design and Develop for Security

Design for SOA

Patterns

Building Blocks

Artifacts

Methodologies and Techniques

Quality Attribute Skills

Business to Technology Strategy

Alignment and Investment Strategy

Valuation

Industry Concerns

Business Fundamentals

Business Community Organizational Aspects

IT Environment

Organizing

Engineering

Operations

Governance

Project Management Capabilities

Human Dynamics

Communication

Situational Awareness

Leadership

Product Management

Business Analysis

Business Process Analysis

Business Process Execution

Development

Design Documentation

Unified Modeling Language

Entity Relationship Diagrams

Object Oriented Design Patterns

Testing

Test Planning

Defect Management

Reporting

Resource Planning

Daily Test Process

Testing Environment

Function Testing

Security Testing

Usability Testing

Regression Testing

Performance Testing

System/Integration Testing

Build Management

Unit Testing

Automation Testing

User Experience

Usage Scenarios

Sequence Modeling

Business Process Modeling

Unified Modeling Language

Activity Diagrams

Sequence Diagrams

Use Case Diagrams

Business Process Analysis and Design

User Interface Design

Release Management

Deployment

Network Architecture

Operations Manuals

Installation Instructions

Pilots