The importance of repetition

How often do you remember someone's name after having met them once and then not seeing them again for one or more years later? What's the liklihood that you'll remember the name after you've met that same person a few different times, or after you've spent some length of time engaged in meaningful conversation with them? Probably significantly higher, right?

The same is true of any idea though, isn't it? Oftentimes as architects, we have knowledge and experience gained from doing several projects over several years. This certainly doesn't mean we know everything, but it does mean we oftentimes possess a lot of wisdom and experience that others don't possess. Try as we may, with the best intentions we try to share that experience and wisdom with others, then oftentimes, get frustrated when the others don't "get it." I discsused this concept in further detail in an earlier post titled "Sooner or later, everyone will touch the stove."

So, just as the liklihood of your remembering someone's name the second or third time you've met them or spent some meaningful time speaking with a person, what you're trying to convey to others will be remembered the more often you say it, the way you say it, or the more often you engage with others in meaningful conversation around it. This phenomenon is not something to be frustrated about...it's simply a phenomenon worth acknowledging and appreciating. Several other fantastic strategies for making your ideas "stick" with people are detailed in the book Made to Stick: Why Some Ideas Survive and Others Die, by Dan and Chip Heath. If you want your ideas to "stick"...and who doesn't?...I highly recommend reading it.

Effective architects use several strategies to make their ideas stick.

The complexity condundrum

Albert Einstein once said that "Everything should be made as simple as possible, but not simpler."

The quote is profound on one hand, but terribly ambiguous on another :). I recently read an article by Clay Shirky that covers his thoughts and impressions of a book written by Joseph Tainter titled The Collapse of Complex Societies (which I haven't read), but the article talks about some thoughts from the book, particularly the idea that the only way for societies that have gotten too complex to simplify is to start over. Hmmm...take a moment to think about that.

Why is that suggested? According to the article, Tainter references several societies that at one point, were the epitome of progress...take ancient Rome for example. The problem is that they had also become so complex, he argues, that they effectively collapsed under the weight of their own complexity. He proceeds to suggest that maybe there is no other way to simply when societies reach a certain point in their lifecycle. When I look at the complexity in governments, and many organizations I've worked in as a consultant over the years, I have to say...I also tend to wonder if there is a different viable "solution" to the complexity problem myself. It's an interesting (albeit rather depressing) idea that has some sound facts and arguments to support it.

Contrast this outcome with a much more optimistic outcome detailed in a book titled Simply Effective: How to Cut Through Compexity in Your Organization and Get Things Done, by Ron Ashkenas. He suggests that complexity has 4 major causes:

• Constant changes in organizational structures
• Proliferation of products and services
• Evolution of business processes
• Time-wasting managerial behaviors

Whether you agree that these are the major causes or not, I'm sure you'll agree with me that these are certainly at least some of the major causes. What I liked about Ron's book is that he doesn't take the route of suggesting that the only possible way to simply is just to throw your hands up in the air and start over, but rather provides some good suggestions for how to minimize complexities in these areas. These suggestions aren't just changes that can be made at the top, but include changes that can be started with people at any level of the organizational hierarchy. If you have the book, or search Google books, you can find several of these suggestions on pages 178-179. I highly recommend reading the book...it's fairly short, and contains a lot of great information. If you want to be even simpler :), read Ron's blog.

Effective architects understand the value and importance of simplicity, and strive to make things as simple as possible...but not simpler :).

Forecasts for technology architect jobs: Increasingly sunny after a few more years of stormy skies

In the world leading up to a few years ago, the IT industry had become increasingly specialized. Specialized products and people with very specialized skillsets. Of course, a lot of that is still prevalent today. As a result of this, many employers then wanted to hire people with specialty skillsets to deploy and operate their specialty products. In the last 20 years in the IT industry, the need for an architect has certainly existed, but has gone largely unrecognized. Why? Architects tend to have a breadth of skills across many areas, and are oftentimes, no longer experts at any specific technology. If a hiring manager is implementing product X though, they want a specialist on product X, not someone with a breadth of skills across several areas. Sure, some companies have architects on staff, and some companies actually know what to do with them, but many do not. This has created a bit of a gap in my opinion, in that architects only have job opportunities with companies who actually understand their value.

Thankfully, the times they are a changin' though. With the advent of cloud computing, and the notion of delivering IT as a service, I believe that organizations who don't know what an architect is, or what their value is, will soon start to realize it. As these companies start to move some of their IT services to providers, they'll discover that a hole exists in their existing staff's skillsets. They'll discover that they need people with skills to coordinate all these disparate systems and also that they have a surplus of specialists, some of which may be able to fill this void, but many that will not. So they'll recruit new people with these skills. They may not understand that someone with these skills is often called an architect, nor is that even important, but they'll at least recognize the need for the skills. When this happens, I believe the job forecast for architects will grow at a significant rate.

Unfortunately in the meantime, architects still face the minimal roles that exist in the marketplace today because many companies have yet to recognize the need. If/when companies figure out that these skills are often possessed by someone called an architect, they may even seek someone with an architect certification (such as the IT Architect Certification (ITAC) from the International Association of Software Architects (IASA)), although it remains to be seen if certification will help in the way that it did for all the "specialist" certifications of years gone by. Regardless, if you're an aspiring architect and trying to determine what skills you might be missing to succeed in the role of an architect, I'd at least recommend checking out the IASA Architect Proficiency Matrix...you'll find you need a lot more than just technical skills!

So existing architects...continue being effective ones, and aspiring architects...start rounding out your skillsets. I believe it's a career with a bright future...provided you can continue to weather the stormy skies for the next few years :).

Update
Since I posted this I came across a couple of articles that are also worth a read and related:

• IT Careers 2020: Cloudy days ahead (from Computerworld magazine) and its tagline "When the cloud blots out the classic IT shop, only the tech-savvy business experts will weather the storm."
• The Rise of the Chief IT Architect (also from Computerworld magazine) which contains the following quote: "The most difficult set of skills to recruit are blindingly brilliant IT architects," McDermott says. "It's an almost impossible job because of the scope of process knowledge you need to possess and the scope of [technical] knowledge you need on how to enable that process architecture."

Why didn't IT deliver "services" sooner?

No, I didn't disappear. Yes, it has been a LONG time since I've posted. Why? Well, I changed jobs shortly after my last post and moved across country. In my new job I just haven't had the same amount of inspiration for posts :), but I have one now.

You are probably aware of the ITIL framework for IT operations. For years it has been espousing the benefits of why IT should be delivered as a service to users, since they don't really care about the myriad of technologies used behind the scenes to deliver it to them. Yet, try as they may, many IT departments have failed to deliver IT as a service. I've worked with many organizations that have tried admirably, and others that have re-organized themselves around the concepts in ITIL, thinking that will do the trick...but most of these efforts have fallen short. The question is why?

I'm sure there are several reasons, but I offer the following food for thought:

1. IT services are delivered by a combination of people, process, and technology.
2. Technology is specialized...routers, storage devices, operating systems, applications, etc. These technologies were largely built for their purpose...not necessarily for the purpose of being delivered as part of a larger service.
3. People built careers specializing in these technologies, which caused disconnected skillsets and departments...that were also, off trying to accomplish their specialized function in the organization.
4. Processes were then developed to get things done across these multiple organizations...and as a result, we have the people, processes, and technology that we had up until a few years ago.

I say a few years ago because that's about when the notion of software as a service, and X as a service really started gaining popularity. It became part of IT pop culture. Ultimately though, it showed users what was possible...a way to quickly and easily get some specific functionality (E-mail, CRM, etc.) that didn't require a large capital investment, that they could pay for as they consumed and that they could get an SLA around. That's all they really wanted...IT as a service!

The significant difference in what a service provider offers and what traditional IT offers however, is what they were built to do. The service provider was built from the ground up to deliver IT as a service. Most IT organizations were not built to do this. As I mentioned previously, many are trying to morph to it, but sometimes it's easier to just start over, isn't it? Some organizations will do this...the Bechtel Corporation, which I also referenced in an earlier post, is a prime example of one that did. Many more will not. Regardless of whether IT starts over or not though, the cat's out of the bag. Users want IT delivered as a service, and that's what they'll get, whether it's from their IT department, or someone else.

Precision questioning and answering

Of course architects don't have answers to all questions, but it's critical that they know how to ask precise questions. Sure, you know that, and you've heard it said many times before but I do want to focus on it for this post. I've worked on many projects over the years where people simply asked unclear questions and as a result, got unlear answers.

I certainly don't mean to imply that the person you're questioning doesn't also play a part in the process. If person A asks an unclear question, person B is equally obligated to ask clarifying follow-up questions, but oftentimes, users don't know which questions to ask so ultimately, asking the precise question falls back on the architect, program/project manager, etc. The impact of unclear questions and answers is unlimited however. Having spent many years as a consultant, I've seen multi-thousand person divisions of companies head down the wrong path for a year because their leader didn't ask clarifying questions of their leadership at the start of the year, likely for fear of looking incompetent. At the end of that year though those leaders incompetence became abundantly clear as they "decided" to leave the company and go "spend more time with their families." If you're not clear of what you're being asked for, ask clarifying questions, your success and everyone else's depends on it.

"Judge others by their questions rather than by their answers" --Voltaire

Of course there are many styles of questions (open-ended, close-ended, etc.) and effective architects must know which situations warrant the appropriate questionning style, but in any case...be precise in your questionning...and, equally important, in your answers. Avoid using vague terms in questions such as "When will you be finished?" if you and the person you're asking don't agree on what the word "finished" means. If you're asked a yes/no question...answer it with "yes" or "no"...not an explanation that requires the person asking the question to infer whether the explanation actually equates to "yes" or "no." This requires you to be very deliberate in what you ask and answer...and it's not a skill many are proficient at. You certainly can get better at it though, and must if you want to increase your effectiveness.

A wealth of resources to help you improve your questioning and answering skills are available at Vervago's PQ & PA Skill Sharpener site. Additionally, a good 3 part series on questioning principles can be found at the Creative Streak blog.

Be accountable for your actions & hold others accountable for theirs

The highest performing teams that I've worked with have the best mix of:

• Each individual on the team knowing their responsibilities (and the ability and ambition to execute them), as well as the responsibilities of their teammates.
• A commitment by everyone on the team to execute their responsibilities to the best of their ability...all the time, as well as a commitment to provide respectful, direct, and honest feedback to their teammates when they're not executing on their responsibilities.

Does this mean you don't help teammates when they're not at their best? Absolutely not...but there's a big difference between helping people and trying to do their jobs for them because you believe yourself to be better than them at it. Trust me, you're not.

Over the years I've worked with many people that either aren't completely clear of their own responsibilities and/or their teammates' responsibilities, their teammates aren't completely clear of their own and/or their teammates', or most often, some combination of all of these. There's a word for this...it's called anarchy.

Imagine a football team where nobody really knows what their responsibilities are exactly. Do you think they'd ever complete a play successfully? Do you think they'd ever win? Sure, maybe sometimes, but their ability to do so would largely be by chance. If you don't fully understand your responsibilities, get clarity from who you need to so that you do. If you don't fully understand your teammates' responsibilities, then get that clarity too. Once you have that clarity, be the first to admit it when you don't execute well on your's. Additionally, be the first to respectfully and directly speak to your teammate when they don't execute well on their's (though of course, the "pick your battles" rule always applies).

The book Crucial Confrontations is in the Recommended Reading list for this blog, and is a great tool to help you with these conversations. The worst thing you can do is go around people you believe aren't doing their jobs, at least not based on what you believe their job to be. This doesn't fix problems, and unfortunately, often creates more. The next worst thing you can do is to try to do people's jobs for them. This is just irritating, patronizing, and insulting...not to mention it takes you away from what you're being paid to do. Don't do it...you don't want people trying to do your job either. Instead of doing these things, provide respectful, actionable, and direct feedback to people. It will help them improve, and most people are thankful to those who help them improve.

Effective architects give effective feedback, are accountable for their actions, and hold others accountable for their actions because they know that's the only way problems really get solved. A resource that effectively illustrates this and other attributes of dysfunctional teams is the book titled The Five Dysfunctions of a Team: A Leadership Fable. It takes an interesting approach in that the "lesson" is told through a fable played out by characters. Though the "team" is an executive team in the fable, the underlying problems they face will resonate with you in different teams you've been on I'm sure.

Technology breadth and depth

While all architects were experts in certain technologies at some point in their careers, they now spend more time learning all they can about as many different technologies as they can rather than spending significant time learning all there is to know about a few technologies. Why? Because effective architects make the best (rather than right, see separate post for more on this topic) technology decisions to solve specific business problems. To make the best decisions, they need to know a lot about a lot of technology. There are simply too many technologies and too much too know about each one to stay deep in a given technology for long. So, what does it mean to know a lot about a lot of technology? Consider the following steps:

1. Start with a technology area, say customer relationship management (CRM) software, programming languages, operating systems (OS), etc.
2. Research to determine what offerings exist in the area selected in step 1. For example, if the area were personal computer operating systems, you'd identify Windows (multiple versions), Unix (multiple varieties), Mac OS (multiple versions), and Linux (multiple distributions) for starters. An excellent resource to start you down the road to identifying areas and offerings are the IT Roadmaps, developed by Jeff Tash.
3. Determine the pros/cons for each offering identified in step 2. You can often find product comparisons with simple Internet searches. Of course, comparisons can be biased based on who's doing the comparing, so be sure to read multiple comparisons from multiple sources. The pros/cons shouldn't just be based on feature/functionality, but also on pros/cons in meeting service level requirements for scale, availability, fit with existing software products, etc.
4. Select another area and complete the process again.

For each of these steps, you'll of course want to prioritize based on what's most important to the current position you hold or project you're working on. At this point though you'll have a fairly good breadth of knowledge in the areas you've researched. So what's depth then for an architect? Within the area you selected previously, complete the following steps (for starters) for each offering:

1. Understand the key components of each offering and how they relate to each other. For example, a CRM offering typically has an application server component and a database component. Each of these components may further have dependencies on specific database and OS technologies.
2. Understand the authentication options available for each offering and which options are relevant for your project.
3. Understand the offering's dependencies, and how those do/don't coincide with your existing environment.

Armed with this knowledge you can now begin to make the best technology decision for a given project, as well as in the future, though of course, you'll need to refresh your knowledge over time. Certainly, during implementation you'll learn even more about the chosen offering, but once its implementation is complete you may not ever touch it again. With all of the offerings available in different areas, it's almost impossible to stay current with it all, and it's certainly impossible to stay deep in a specific technology, unless you are a specialty architect. Effective architects' depth lies in multiple offerings across multiple areas, whereas technologists' depth within an offering is deeper, but less broad.