8 years, 2 months ago

Be GREAT !

Do you ever find yourself in the situation where you can be of help in several very different efforts that, although seem valuable at the time, randomize your brand…not to mention stretch your time and affect your work/life balance? I certainly do. I think this happens as a result of having a broad set of skill sets, with broad visibility in the organization, a hunger to serve and lead others, and a depth of skills honed from an engineering background to help decompose problems and derive solutions.

Anyway, if you’re like me, you may also value a simple technique I use to help filter what efforts to commit to addressing. I call it ‘Be GREAT!’ and it is a derivative of Jim Collins’ Hedgehog concept but instead of applying it to identify business strategy, I also use it to identify services I can offer to my team and to the company at large.

First, let me briefly describe the Hedgehog concept. Essentially, Collins asserts that great companies have products that have an association to three important characters; Passion, Position, and Value. If a company’s products lack one of these three characters, then they will likely be good or mediocre at best. If, however, your company is passionate, well-positioned and has perceived customer value, the company can be great.

Hedgehog

I think this concept is very interesting and I apply it to my career, my team, and my organization. That is, I use the Hedgehog concept to rapidly guide decisions to help identify which skills I deliberately improve and grow, what efforts I guide my team to commit to, and to which services my organization commits to.

So there are three essential Hedgehogs to consciously manage; My Hedgehog, my Team’s Hedgehog, my Organization’s Hedgehog. When I’m able to directly connect all three, you, your team, and your organization can be great.

My Hedgehog: My Hedgehog refers to my skills. If the situation arises where an effort I commit to leverages my skills that I’m passionate about, where I’m well-positioned to leverage these skills in the effort, and my skills are perceived as valuable by the team, I consider committing to the effort.

Team’s Hedgehog: Team’s Hedgehog refers to the services or outputs of the effort. If the effort directly delivers value to the organization, if the effort is well-positioned in the organization, and the team driving the effort is passionate about the output, the team can be great.

Organization’s Hedgehog: Organization’s Hedgehog refers to the services the organization delivers to it’s customers. I think of organization synonymously as company – no differently to how Jim Collins describes it but extending it to Organizations within a company as necessary.

Here is a simple diagram illustrating the synergy that can be achieved when all three hedgehogs are intentionally connected.

Hedgehog Synergy

In the above diagram, I added the dimension of Time to only recognize that if this concept is deliberately managed, there is a sequence to determining how an Organization’s Hedgehog relates to a Team’s Hedgehog, to My Hedgehog.

The “Be GREAT!” method quickly helps me intentionally avoid being mediocre and deliver on being great, guide my team to be great, and directly support the organization and company be great. Way cool. 🙂

9 years, 6 months ago

Inappropriately comparing Building Architecture and Software Architecture

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

10 years, 3 months ago

Tips for gaining adoption

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.

 

 

10 years, 11 months ago

SWABOK, Archipedia, Uber Architecture Framework, xyz?

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.

11 years, 21 days ago

Enterprise Architect vs Solution Architect

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 …