8 years, 5 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.”

8 years, 7 months ago

Why Getting Past “But…” is Important

You’ve probably read Getting to Yes and heard of Getting Past No, so why Getting Past “But”? Well, because “but…” is insidious, making it harder to get past than an outright “no.” The person who says “yes, but…” is ostensibly aligning with you. Ostensibly agreeing but for this teensy caveat—this objection that is a showstopper! […]

8 years, 8 months ago

Scaling Agile with VAP: Getting Past “But…”

Our Getting Past “But…” executive report covers two essential areas:

innovation, the circles of innovation model, the innovation process, and what all this means for architects.

scaling agile development projects with VAP (emphasizing just enough design upfront or JEDUF).

These map roughly to the first and second halves of the report, though we encourage those interested […]

8 years, 9 months ago

Video of eXploratory Modelling at ESUG2008 available

Today James Robertson published his video of my talk on eXploratory Modelling at ESUG2008: http://www.cincomsmalltalk.com/blog/blogView?showComments=true&printTitle=eXploratory_Modeling_at_ESUG_2008&entry=3404625062 Have fun watching it, and please do not hesitate to contact me if you have questions or if any part of the presentation was unintelligible because of the noise or such.The presentation was done without a microphone, and I guess […]

8 years, 9 months ago

Meet WALL•S!

Though not called WALL•S by Michael Haupt who posted this blog, the little NXT robot in the picture immediately reminded me of WALL•E. So meet WALL•S, the first robot that actually speaks and understands Smalltalk! Some of you may know that Smalltalk originally was quite popular in the embedded world. Tektronix for example ran Smalltalk […]

8 years, 10 months ago

Smalltalk on bare metal blog

Nice blog by Cees de Groot about the SqueakNOS project that has been revitalised. This project has my special interest since it clearly demonstrates some features of Smalltalk in the sense of it’s completeness. We are not talking programming language. We are talking system.

9 years, 16 days ago

Achieving Model Traceability: Finding the Traceability Critical Path

We all agree now that Adoption is key for Enterprise Architects. And the trick to adoption is resonating with those that make change and influence them to make the change that is best for the enterprise. In a previous blog post, I introduced the Solution Model concept. In this post, I want to talk about the concept of the Traceability Critical Path, which is the portion of the Solution Model necessary to trace from Strategy to Code.

Support for Solution Architects is good

As Solution Architects, we have the ability to understand a business problem and be able to derive a software solution to meet the business problem. We have lots of process tools to help us such as software development lifecycles like Microsoft Solutions Framework (MSF), Extreme Programming (XP), Rational Unified Process (RUP) to describe who does what and when. We have methods such as Object-oriented Design (OOD) and Attribute-based Design (ADD) to help use design software components. We have vibrant software engineering organizations and user groups like IEEE, OASIS and Software Engineering Institute (SEI) to leverage. We have knowledge bases to leverage such as the Software Engineering Book of Knowledge (SWEBOK). We have system design tools such as Visual Studio to design, develop and deploy software. Pretty good.

Support for Enterprise Architects is good

As Enterprise Architects, we have the ability to understand all of our business organizations and derive IT architecture for the entire enterprise. We have lots of tools to help us such as Enterprise Architecture Frameworks (EAF) like Gartner’s EAF, TOGAF, Federal Enterprise Architecture (FEAF). We have industry organizations and user groups to leverage such as ISACA/COBiT, ITIL and TMForum. We have methods to identify and focus on individual business pain points like MSBA’s Business Capability Analysis and Six Sigma/Lean to avoid analysis paralysis. We have tools to help manage enterprise information such as business processes, project and application portfolios from Microsoft, Troux, MetaStorm and Sparx Systems.

We need a way to connect Enterprise Architecture to Solution Architecture

So, here’s the problem, the outputs of all the tools and methods need to be connected so that we can trace from “strategy to code”. You may have heard other catch phrases trying to say the same thing such as “connect planning and implementation”, “deliver to the plan” or the phrase “help an organization determine the right things to do and ensure that project teams do them right”. Isn’t it funny how there are so many catch phrases out there trying to describe the concept of Model Traceability?

Model Traceability connects Enterprise Architecture and Solution Architecture

My team thinks that Model Traceability is very important and we have invested in this area to help us make sense of all the tools and methods out there in an effort to streamline what’s important so that we can honestly and justifiably say we know what are the right things to do and we can trace them to project teams and show how they are doing them right. During this effort, we have discovered some very interesting things.

We evaluate the tools and methods and identify what concepts they produce or mange. We then evaluate these concepts and determine what value they bring to their stakeholders; concepts such as Business Strategy, Business Capability, Use Case, Business Process Activity, Application Interface, System, Code, Test Case. We then determine how they are associated to each other. For example, A Business Process composes Business Process Activities. Automated Business Process Activities use Applications.

Without the metamodel, we might have a mess like the diagram below illustrates.

MetamodelMess

Disclaimer Note: The diagram above is not representative of my team’s metamodel in order protect Microsoft IP. I deliberately used inappropriate elements, removed several elements, removed all associations between the elements, and spatially organized the elements somewhat randomly.

There are lots of concepts involved, we need the Traceability Critical Path to understand the explicit connection

Our goal is to get to what we are calling the Traceability Critical Path. The Traceability Critical Path (TCP) is the set of lowest-level elements in the metamodel that have an explicit association with each other that are necessary to trace from Strategy to Code. [I know, bad acronym choice. We might later rename it to avoid confusion.] Identifying the TCP elements and how they relate is the goal of this work. Then, connecting the rest of the elements to the TCP elements to understand how they relate.

Along the journey of defining the TCP, we discovered some interesting characteristics of the metamodel elements. We found it useful to differentiate between element types. Here are some examples:

  • Traceability Critical Path elements. Elements that have a direct or concrete relationship from planning activities
  • Enabling elements. Elements are really only methods or tools to derive critical elements.
  • Temporal elements. Elements that act as placeholders for required elements but are needed at a later time in a process.
  • Discipline-specific elements. Elements that are useful only to certain disciplines but are somewhat meaningless to others.
  • Associations elements. Elements that describe how elements are related/associated with each other.

We had some interesting observations made along the way worth sharing

Along our journey we made a few interesting observations that maybe, at some point, I’ll dig into later because each could take a while to explain. But for now, I’ll just jot them down to share:

1. Complimentary Information Model. In addition to the metamodel, we created an information model to describe the concepts the elements represent because there are times when identifying individual elements, the resulting element’s names don’t easily resemble the original concept being evaluated and causes a bit of confusion. We required an information model to describe aggregations, compositions, generalizations and subtypes to keep the metamodel meaningful by the different audiences.

2. Enabling and Temporal Elements and Abstraction relationship. We observed during the exercise of building our metamodel that the relationship between the Enabling Elements and degree of abstraction. We noticed that many of the Enabling and the majority of the Temporal elements tend to exist at higher abstractions and the TCP elements tend to fall in the lower abstraction. This trend is illustrated in the graph below.

MetamodelTrendType

3. Gaps in enterprise planning concepts. When analyzing the trend data, we found gaps in our scatter graph. We are wondering how to explain this and what to do with this observation, but we are leaning to spend a bit of time to apply some engineering rigor and define enterprise planning concepts in more detail. The types of concepts are those that describe Business Strategy and Business Model as examples.

MetamodelTrend

Summary – The TCP brings very interesting benefits

Having the metamodel and clear identification of the TCP within it, we get a lot of benefits such as:

  1. Objectivity. Ability to put the tools, methods and concepts from several disciplines into perspective and help us get to the crux of their value proposition to enabling elements in the TCP.
  2. Impact Analysis. Ability to traverse the model and do Impact Analysis from any element of concern. For example, one can identify which applications are involved to enable Scenarios. Or, one could identify which System Features impact Customers or Business Partner and so on.
  3. Role Clarity. Ability to understand the disciplines and roles that typically create elements fit into the planning and implementation activities.

I would like to share our metamodel, complete with the TCP, as well as the process used to build it. But, to be fair, this is a team effort and I want to give credit where credit is due as well as respect the fact that this is the property of Microsoft that I don’t have approval to publish yet. If you’d like to see our metamodel, let me know and I’ll bring your request to my team.

Categories Uncategorized
9 years, 1 month ago

Lessing, Doris: Shikasta

Rating: Dit is niet één boek, maar de eerste van een serie van 5 boeken die Doris Lessing geschreven heeft in een science fiction format. Sommige van haar eerdere werken neigden al een beetje naar dit format, maar met Shikasta is zij er volledig ingedoken. In het nawoord heeft zij ook het beste betoog geschreven […]

Het bericht Lessing, Doris: Shikasta verscheen eerst op Rob Vens.

9 years, 1 month ago

Valuing the Undervalued Solution Model

Modeling helps improve the success of delivering a high-quality solution

A primary responsibility of a Solution Architect is the integrity of a given project’s software solution. There are many aspects to a solution’s integrity such as System Quality as well as Traceability to ensure the software actually meets the business needs. There is another that is the topic of this blog post and is a Solution Model. Of course, a model by itself won’t guarantee a high quality solution or traceability. However, if done right, it could and it could help you get there faster.

Keep it simple – Use modeling to describe the problem, the solution and how they relate

Let’s sync on the term Solution Model. It’s actually quite simple. I’m referring to the concepts or artifacts a project team manage that:

  1. Describe the business problem. For example, concepts such as Business Process, Customer Scenarios and Requirements.
  2. Describe the solution. For example, concepts such as System Features, User Interfaces, System Interfaces, Data and Source Code.
  3. Describe how they are tied together. This bit is really important. This is where you define how the concepts are associated for Traceability. For those familiar with Software Factories, this is similar to the concept of a Software Factory Schema.

Getting modeling adopted is hard

Project team members naturally think myopically and avoid contemplating the needs of other team members or groups that depend on their information. Because modeling a Solution Model requires tying all the concepts together across the project team, you can imagine the many challenges to get it adopted by the project team. For example, here are few challenges a project team might face during efforts of gaining adoption:

  1. Proving the model’s value to the business stakeholder’s to get buy-in isn’t easy. Without business sponsorship, getting modeling adopted by the entire project team will be a tough hill to climb.
  2. Proving the model’s value to the project team to do the actual modeling. Ideally, everyone will build their portion of the model as part of their responsibility of solution delivery. The challenge is to get the team to do it, and proactively.
  3. Determining the role of the model in a project. This is really important, many modeling philosophies out there assume a model-driven approach. I don’t agree with this assumption. Modeling has several dependencies that dictate the value modeling brings to a project. For example, models can be use to kickstart the architecture (think MDA) and then it could be, and appropriately so, discarded. Or, it could be used to drive the development (think MDD) with roundtripping, therefore living throughout the lifecycle of the project. Or, it could be used for reflecting what’s already in place for maintenance activities post release of the solution.
  4. Determining the right level of model maturity for each model. This is about understanding how much rigor will be spent on the models to establish expectations of what the models will accomplish without compromising the model integrity. This is a project-by-project decision, heck, even a model-by-model decision when you get down to it. The important point to remember is to make sure the level of maturity isn’t too stringent while at the some time the level isn’t too low that it doesn’t compromise the integrity of the Solution Model.
  5. Having modeling skills and modeling tools available to the project team to do the actual modeling. It seems simple but the reality is this can be a big challenge. I suggest short simple modeling activities as a start to benchmark the team’s modeling skills and work from there. Once the initial kinks are worked out, look to automate the modeling process with a modeling tool. Oh, there always seems to be the need for a modeling SME – someone to the hold modeler’s hands, manage the model repository and do brownbag training sessions. It’s good to keep this in mind and allocate resources just in case during project estimation and team readiness activities for a dedicated modeling SME.
  6. The right number of modeling tools. There will also be multiple tools in play. For example, business representatives will prefer business requirements requirement management tools like Visual Studio Team System or Compuware. Business process people will prefer specific process modeling tools like Provision and Corporate Modeler. Information Architects will prefer Erwin or Enterprise Architect. System Architects will prefer Visual Studio Architecture Edition or Enterprise Architect. Tools are a personal choice to most people. My advice to you is to allow people to choose their own modeling tool AS LONG AS:
    • The tool supports XMI import and export and
    • it is an actual modeling tool, therefore, no word editors, spreadsheets, slide decks, etc.
    • there is a single proper modeling tool which the Solution Architect can use to collect (via XMI import) the other models into a single tool and associate model elements for traceability

It’s not about modeling philosophy – focus on the aspects of modeling that bring value to the team

This blog post is not a stroll down theory lane. Although theoretical Modeling concepts, scientific modeling philosophy or modeling methods and paradigms such as MDA, MDD, UML and DSM are interesting, they are about how to model. That is, modeling methods, modeling diagrams and modeling notation. Instead, this blog is about understanding the value of modeling to a project team and is focused on helping Solution Architects gain a practical understanding of the value of modeling to, in turn, help explain its value to the project team for adoption. Because, in the end, without adoption theory is pointless in our efforts to improve system quality and optimize the business investment.

Sidebar: A Model is not the same as a Diagram. There always seems to be a bit of confusion around this, so I thought I’d make this note. A diagram is merely a View or picture. A Model ensures that the model elements on a diagram have specific meaning in both what they represent and how they relate to other model elements. There could be diagrams of a model but if the diagram doesn’t have an underlying model to ensure integrity of the model elements, it is only a picture. Although a diagram is useful, it can be misleading because it is probably inaccurate and only represents a point in time.

Models provide tons of value – the trick is describing it to the project team

So, what’s the value of the solution model? Below is a list of value statements to try and answer that question and is the main purpose of this blog post.

  1. Consistent Terminology bringing clarity and team scalability. Models provide a consistent language for describing the business problem and how the solution will address it bringing clarity to the entire project team. When resources talk about concepts like Business Process, Scenario, System Interface, etc the entire project team is crystal clear what those are and how they relate to other concepts. This also makes it far simpler to get additional resources ramped up as the project team grows.
  2. Team Focus. Improve the focus of the delivery team to solving the business problem and not get sidetracked or distracted. If the business problem is modeled well, the development team is more likely to understand the challenge at hand and avoid misinterpretation of what the business wants. This is unbelievably useful to ensure that the project team build what they need and not superfluous concepts not in the Solution Model or, at least, minimizing additional effort not already clearly described by the Solution Model. Essentially, each model element become work items and higher priority than concepts not useful by other team members.
  3. Improves the chances for a highly Functioning Team. Similar to #2 above, with a well-defined Solution Model, a team begins to partition what concepts each team role is responsible for and which concepts they depend on from other roles in the team. Therefore, team members are avoid miscommunication with their work products and avoid unintended duplication of effort.
  4. Enhanced Requirements Management through Traceability. This has to do with the ability to easily navigate how pieces of the business problem are being addressed by the solution design. With a Solution Model of the business problem and traceability to concepts that describe the solution, business stakeholders can readily see what bits are being developed that relate to the specific areas of the business problem…and which bits do not. It also enables engineering teams to understand explicitly which portions of the business problem are affected by system design or enabling technologies. This is particularly useful in the inevitable situation when technology limitations are discovered and engineers wish to know which business representatives to go speak to.
  5. Reuse resulting in accuracy. Having a model of the concepts the team manage can effectively reuse concepts where appropriate. This is super important. Take the example of a business entity. If you have a data model of the logical information entities, the team can associate processes, business rules, application interfaces, etc to the information entity, therefore, modeling reuse of that information entity. The value is clarity in the information and avoidance of duplicate information entities resulting in information accuracy. This is just an example using a model of information entities in the solution model. The same could be said for application interfaces, business process activities or any other concept.
  6. Early warning system. Ability to perform litmus tests if the solution meets the upstream business strategic goals. Assuming an agile development approach, the solution model implicitly contains traceability from business goals to the solution allowing visibility of the solution bits to be tested and proven effective on the business goals early in the project lifecycle.
  7. Reduce Risk of Scope Creep. Requirements are less likely to sneak into the project scope unnoticed. Including requirements as part of the solution model requires that they be associated to other concepts. Where there is no association, automated model integrity checks would easily identify rogue Requirements.
  8. Reduce Risk of Project Slippage through the ability to keep the team focused on specific artifacts. A byproduct of having a Solution Model is a clear understanding of what the various concepts a project team will manage and what needs to be done with them and when. This helps reduce unknowns or ‘learning as you go’ that can happen ultimately helping keep the team on track and focused on the specific concepts throughout the delivery lifecycle.
  9. Description of the entire business problem. A Solution Model provides a complete description of the business requirements. I’ve bold-italicized requirement because I want to stress that a requirement is simply a generalized description of the problem. It can take the form of process, use case, scenario, CRC or your traditional functional requirement, or something else. The point is that the model describes explicitly which of these will be included giving the model, once filled-in, a complete picture of the all-up business problem to solve.
  10. Enhances Requirements Management. The Solution Model allows Product Managers to manage a finite set of requirements for requirement change control activities. A Solution Model also quickly identifies which portions of the solution are affected by new requirements or changes to an existing requirement.
  11. Description of the All-up Solution Architecture. Obviously, with a model of the business problem and the solution all tied together, you have a complete model of the solution architecture and can create useful views/diagrams that show the all-up business problem, system model, data model, user experience, interaction models, integration model, etc. A well-organized model also allows for views that show how design patterns are implemented to justify and prove system quality. This is a very powerful value proposition. Consider each project team role and from their perspective being able to traverse the solution model in any direction to get a complete understanding of how other areas relate to concepts of your concern. For example, the Test Team may wish to link Test Cases to Source Code, Use Cases, User Experience Processes and Functional Requirements concepts. A Solution Model inherently provides this. Now, when Test Cases pass, the entire team will know what source code passed and what business requirements and user experiences are now enabled.

You might be wondering about where Project Documents fit into this story. A Project Document, in my opinion, is nothing more than an artifact created for sign-off. I don’t think that there are Project Documents that must be created for every project. Identifying which Project Documents to create and their purpose is a decision by the project team directly. There is no hard rule which to use for all projects. Now, what goes in them, I care deeply about. The content of any Project Document should reflect that model. Therefore, a Project Document composes model elements via Views that are designed for a specific set of Stakeholders and their Concerns. Ideally, Project Documents are built/populated from the Solution Model to ensure that the content is accurate.

Here’s a simple diagram illustrating how Model Elements, in this case a Requirement, Use Case and Process Activity related to a Project Document using UML notation.

image 

In Summary – a Solution Model is highly valuable. It is worth the effort to get it adopted by the project team.

I covered a lot of ground in this blog post and am talking about an area of modeling not well addressed in the industry. There is tons of information about modeling but little to no information about the business value of modeling nor how to get it adopted by a project team to help a Solution Architect be successful ensuring that a high-quality solution with integrity is delivered. Remember, there are lots of challenges to get a Solution Model adopted. But I hope that through the list of value statements, you will be able to convince your audience to adopt the Solution Model.

Categories Uncategorized
9 years, 2 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.