The Politics of Design

Are App Stores replacing the web?

noreply@blogger.com (Mike Alvarez) — Wed, 06 Jul 2011 02:44:00 +0000

Absurd? Impossible?

Consider this: When you use your mobile device (smartphone / tablet / other) to check the news, movie reviews, World Cup standings, price of your stocks, buy a birthday gift or check the weather what app do you use? Do you use Safari / Android browser or an app built with a specific purpose such as Instapaper, IMDB, ESPN ScoreCenter, Bloomberg, Amazon or WeatherBug? I'd bet that more and more of the information you consume and the transactions you conduct are via apps rather than Safari or the Android browser.

The web is, and always will be, a tremendous resource for research or when you don’t exactly know where you want to end up but for targeted information such as news, weather, purchases, paying bills, my primary tools are apps, not the browser.

Why?

It's simpler, cleaner, more efficient and more direct. If I use IMDB's app rather than IMDB's site to view ratings for a movie, I have less typing and tapping. I also reduce the risk of someone SEO-ing me into a site that I did not want to visit or allowing myself to get distracted into hours of endless surfing. Or, in the case of WeatherBug's site, I can avoid the animated advertisements for weight loss with someone grabbing their beer-gut. It is also cleaner because the format of the app is optimized for the device I am reading it on.

The way I consume information is changing as more of the places I visit release apps. Most of the reading I do and more and more of the transactions I engage in are via a mobile app. On a recent business trip I was able to check into my Southwest flight via the Southwest Android App. The app presented me with a handful of menu options where the Southwest.com site has dozens. I could have achieved my goal using the Android Browser or the Southwest app but the app was much easier to use while I was trying to pay attention to a presentation.

If you "buy" this theory and you also believe that the majority of internet access will be over a mobile device rather than a desktop device by 2013 (Gartner) then it stands to reason that App Stores and Markets will begin to replace the web as a portal for information and your company. i.e. consumers will search the App Store for an app before going to the web. The Web ends up being "Plan B".

Most mid to large sized companies have millions invested in their web presence but close to nothing (by comparison) in mobile app investment. I am not saying companies need to invest millions in mobile platforms and mobile-presence-management but they do need to prepare for this change and have a strategy that guides them along the way.

Study Access Methods:
Does your company understand how users access your sites? Which platforms or devices are your customers using? What’s the tipping point when mobile device portals (app or web) become the primary focus over desktop web portals? Is it when 30% of your access comes from a mobile device? 50%, 70%?

Manage your company’s mobile presence (think App Store SEO)
What does your presence look like to the average consumer on the web vs the Android Market or Apple App Store? Your company has spent considerable money to ensure when someone Googles “Harley Davidson” (or your company name) that the corporate sales site is on the top of the list rather than some blogger that has learned how to play the search engine game.

What does this look like in real life? Here is an example from Southwest Airlines and Harley-Davidson:

Southwest Google Search result: The first 6 listings are all Southwest Airlines corporate sites, driving business to Southwest. (click image to enlarge)

Southwest App Store search result (iPad): Entering the same exact text "southwest" resulted in the below results in the App Store on the iPad. Southwest Airlines is first in iPhone apps but appears after the iPad apps which essentially makes it 7th in the list. (click on image to enlarge)

Harley-Davidson Google Search result: The Google search for "Harley Davidson" results as we would expect with the top listings (top 4 in this case) being Harley-Davidson corporate sites. (click on image to enlarge)

Harley-Davidson App Store search result (iPad): None of the results are from the Harley-Davidson corporate so they have a large gap between their web and App Store presence. (click on image to enlarge).

Is there a gap in your company's web and app presence?
Try it for for yourself. Use an internet search engine then search using the same name from your iPhone, iPad, Android device. See if there is a difference then ask your Marketing VP if the presence in the App Store / Market represents the view you want a growing portion of your customer base to see.

Go International:
App developers can limit the distribution of their app to certain countries / regions. (At least I know this to be true of Apple and assume it is the same for Android) So, what you see in iTunes with your company’s name on it may be specific to your country. iTunes does allow you to change your country or you can use leaderboard sites like App Annie: http://www.appannie.com/search/ (Apple) or App Brain http://www.appbrain.com/ (Android) to search across App Store and Market and do some quick filtering by country. Plus browsers like Google Chrome allow you to do some quick language translation of the app descriptions to see what it actually does.

Try it out and report back. Do you think app stores will slowly replace web sites as a preferred method for information and business?

Integrate to Win – My Media Manifesto:

noreply@blogger.com (Mike Alvarez) — Tue, 24 May 2011 12:36:00 +0000

Last weekend I was reminded of 3 things:

If you tell a determined 11 year old that something is “not possible” using your reference model of technology, you’ll likely be proven wrong.
Streaming media rocks!
Product integration between devices we use is the critical success factor in market share for Apple, Google and Microsoft.

Some background:
My 11 year old decides he wants to make a slideshow “DVD” …but he doesn’t tell anyone, including me, of his plans. He set’s about his work and barks at anyone who dare get near the family computer to discover his epic production.

Of course, I know something is going on and I have a feeling on how this is going to turn out: hours of effort ending in great frustration when Dad tells him…”that is not possible” just like the time he wanted to make a teleporter or attach a zip-line to the roof of our house or create a race car game that would take a game studio a million dollars to write.

I knew the disappointment horizon was near when he asked me how to copy 6,000 photos between PC and Mac. The kid had spent several hours of time assembling 6,000 photos for a slideshow DVD. I kept coaching to cut out the unnecessary pictures, to “go for the 80/20” to not get too far in this process only to be stopped by the limitations of physical media.

6,000 photos!!! At 5-10 seconds screen time for each photo that would be 8-16 hours worth of DVD!!

With the determination of a pit bull (a.k.a. his mother) he tries to find alternatives on how we could accomplish the mammoth task. Lower quality DVD? Removing some of the photos? Creating multiple DVDs instead one? Just, click on any button on the screen and see if that works!

His determination inspired me to consider alternatives. How COULD we accomplish this impossible task? I’ll skip the failed ideas but it finally hit me that my Apple TV can show a slideshow of pictures sitting on another computer. You can also configure it to play background music from a specific playlist. Viola! Solution!!! A very beautiful and simple one. He was able to create the playlist himself and play the “movie” throughout the day.

Lessons Learned:
One: You can call me stupid for not realizing this was the best solution from the beginning but I was thinking about the primary requirement – making a DVD so other solutions did not occur to me. I was constraining my self with my reference model of how creating a DVD worked. My generation, the generation that is defining the Internet and Mobile and running companies like Facebook and Google and Apple are all somewhat blinded by our reference models. This was a good wake up call that the next generation is tech savvy and isn’t bound by the same virtual limitations.

Two:
I won’t dwell on this point but local physical storage is so 2000 and eight. I can’t wait until someone provides a good solution to store all my purchased media (music, movies, etc) and allows me to store my personal media in the same place. We are closer to this than you may realize. Apple, Amazon and others are already moving in this direction.

Three:
Point two brings me to point three. He who integrates well, will win. Apple, Google, Microsoft – here is my media manifesto: You will win my loyalty as a customer if you can:

Allow me to make purchases of music, movies and other media content directly from the devices I own.
Allow me to view any of the content I own from any of the other device.
Provide me with cloud storage for all of my purchased content so I don’t have to worry about backing it up ever again. BTW, this will make my loyalty sticky because if I have that much content stored in your cloud, I will probably be a customer for a long time…which brings me to the next bullet.
Allow me to export my content in a standard format and port to another platform (e.g. Apple to Google, Google to Microsoft). I know you don’t want to do this.
I also need to ability to store the content I create in your cloud. E.g. my photos and movies.
I want to be able to view my personally created content on and of the devices I own as well.
A final one on my wish list would be the ability to combine my content and share it with others. Home movies, slide shows set to music, etc. I would buy an Apple TV for everyone in my family if there were a “Family channel” my relatives could easily turn on get the latest media created by me.

Apple is close to many of these items but there are still barriers on cloud storage and personal content. I am not asking for cross-platform integration here, yet. That would be nice but I am OK with keeping this within one device / OS platform as long as it works well. So, Microsoft, Google, Apple, shoot me an email when you get this done, please!

Why Android isn’t the best Mobile OS

noreply@blogger.com (Mike Alvarez) — Wed, 22 Dec 2010 14:53:00 +0000

While Google is eating up much of the mobile market today, I am not sure Android will win the mobile marathon in years to come.

Google’s Announcement that Google Voice Search is available through Android based phones and will provide better voice matching to individual speech patterns, once again reminded me of Google’s primary business which is converting data into dollars via advertising. Take a guess at what percentage of Google’s revenue comes from Advertising??

(you’ll find this answer later in the post)

Google excels at making connections. Connecting individuals with knowledge (search), connecting individuals with products, businesses with customers, drivers with destinations, etc. Google’s value (to an end user) isn’t that Google’s Search UI is dramatically better than Bing or they find products or reviews others can’t or that their directions are that much better. It’s that Google makes better connections via their rich and ever expanding collection of information that we provide and Google stores while using these tools.

Google figured out long ago that capturing this data was important so if someone typed “pizza” from a PC Google might show pizza delivery results while someone searching for “pizza” on a mobile device may want to find dine-in restaurants. This connection relevancy is driven by you and me based upon the data we give Google and they store.

Back to the Google Voice Search announcement. Voice recognition is important to many areas of technology from in-vehicle commands, to Call Center IVR to the Xbox 360, and frankly, voice recognition has a long way to go when you consider the differences that occur in speech patterns given different ages, languages and dialects. Imagine all the voice snippets Google can amass and imagine how they can leverage this data when someone searches for “pizza”. It is only a matter of time until Google has the best speech recognition repository in the world which Google can use to make more connections.

Exactly how much does Google make a year to help businesses connect to customers? Try 97% of $23 Billion. Yes, 97% of Google’s revenue in 2009 was based upon advertising revenue. When 97% of your revenue comes from one area, that is not part of your business, that *is* your business. While Google’s revenue did increase from $6 Billion in 2005 to over $23 Billion in 2009, the percentage attributed to advertising is relatively static.

What does any of this have to do with Android not being the best mobile OS? While Google invented another data gathering portal (and a good one) Apple is betting the future of the company on iOS which runs the iPhone, iPad & iPod. It might be a bit unfair to call Android a “data gathering portal” but when 97% of your business is founded on a certain business model, my bet is Android will be extended in a direction that suits Google’s main objective and innovations and investments in the mobile platform will take a back seat.

It will take years for this to play out, but think about this...if mobile is a “fad” (which it clearly is not) which company would be hurt the most if the mobile market vaporized? Google, Microsoft, Apple? I can’t imagine Apple going back to just the Mac and iTunes, I can however, imagine Google moving on after Android and Microsoft moving on after Windows Phone 7.

Maybe I am looking at this from the wrong perspective but I'd like to hear your thoughts.

Android Eats Apple Photo

My New Year’s Resolution: Refine the art of the workaround

noreply@blogger.com (Mike Alvarez) — Wed, 15 Dec 2010 02:43:00 +0000

Refine the art of the workaround - Finding the balance between water and concrete.

Yes, I need to exercise more and yes I need to eat better but this year I am going to try something...well...different (No, not skinny jeans - “thank goodness” say my co-workers) but something that may get me thrown out of the Architect’s Club - WORKAROUNDS.

I spend most of my work-hours influencing others to follow ‘standard approaches’ and ‘prescribed practices’. My teams are responsible for reuse, structure and governance. You’ll find these all over our blog.

However, one art form I have grappled with my entire career is achieving the perfect balance between maximizing *sustainable* forward progress while maintaining the minimal level of structure/control.

In other words, drive the car around the corner at maximum speed without losing control. If you take all corners with great caution in order to guarantee you’ll finish all races, you probably won’t win any. That may be important if the race you are in has other lives on the line (think healthcare) but if you are a startup, the only way to survive (win the race) is take risks.

With experience, you’ll get very good at navigating these corners especially if you’re dealing with some constant parameters. The reality is, life and business are much more dynamic than a car race. You hit obstacles on a daily basis and how you react to the obstacles is the difference between long term success and failure of your IT systems (and maybe your career).

Schools teach one correct way to solve a problem. One solution that will receive maximum points on a test. However, once you enter the real world, you’ll find there are multiple ways of being successful.

Enter Russell Bishop’s new book: Workarounds that work.
Blog Post and Book.

The book is not available yet but what I liked about this post (and hopefully the book) is:
He advocates to find a solution to keep making progress. Too many times I see defeatist attitudes when something does not go the way someone envisioned. They refuse to try again because it did not work the last time.

He advocates choice, as in, you choose how you react to a situation. If you think of something as impossible, it will be, if you chose to push for change, you will probably find a way to make it work. Some IT folk feel they don’t have a choice because they don’t think outside the box appropriately. i.e. the business asked for an estimate in 3 days so my only choice is to hack it in. In most organizations, you have a choice to appropriately push back and find acceptable workaround.

Now, you could easily read my post or Russell’s post/book and twist it the wrong way. As I said in the beginning, I want to find the balance between “water” (path of least resistance-treat everything as a workaround) and “concrete” (every solution must be rigid-never leverage a workaround).

At times a quick fix is necessary and sometimes, you’ll need to push for a more robust solution. How to know what workaround is acceptable? Well, here are a couple reference points.

Poor excuse for a workaround: A crooked road line doesn’t ruin the road but c’mon!!! Take 2 seconds and move the branch for goodness sake!!!

A workaround is absolutely critical: Apollo 13. Maybe one of the greatest examples of ingenuity and workarounds ever seen. Lives were on the line. They had to find a solution and did.

Well, that’s a wrap, so here’s to an awesome, 2011 with fewer obstacles and greater success, but when I encounter the roadblocks that life sends my way, i’ll test out my new pragmatic workaround philosophy.

Have resolutions to share?

Implicit Requirements expose collaboration gaps

noreply@blogger.com (Mike Alvarez) — Tue, 30 Nov 2010 13:02:00 +0000

Implicit Requirements frustrate users, cause project overruns and create an expectation gap between IT and Business. Implicit Requirements are those “common sense in hindsight” items that often go undocumented. They squeak through at requirements reviews because, while everyone in the review nods their heads in agreement, they were agreeing to their individual interpretation of the requirements leaving large gaps for implicit requirements to grow.

Implicit requirements exist in many aspects of our lives. For example, if you’re installing a door on the front of your house you shouldn’t have to specify that you want it to lock, operate smoothly or open and close! EVERYONE understands those requirements. Right?

However, “common sense” requirements are not as clear when it comes to the nuances of business and technology. This is particularly true on Business Intelligence (BI) projects because BI teams are staffed with specialized skills which tend to result in more challenging hand-offs between the various roles (Business, BA, PM, Developer, Architect). This is compounded by long BI delivery cycles, which means the Business does not see the finished product until the final phases of the project.

The Business is reasonable in expecting all rows to sum correctly and “generally known” KPIs make sense (such as not showing $100 Billion in revenue when the company makes $50 Million) but calculations for yield curves and complex interest calculations should not be left as “implicit”.

You might wonder “if IT just understood the business better, it would remove the gaps”, right? Taking you back to the front door example: everyone understands the problem domain (how to use a door) and most can conceptually understand the solution domain (remove old door, install new one, make sure it is level, plumb, etc) but few (if any) understand the complex calculations that Finance and Risk folks use to steer your business AND understand all of your source systems where the data is stored, how to process this data through ETL, Data Warehouse and Semantic layers and finally present it to a user.

Two common approaches to remove gaps are:
#1 Strong Process Solution: Follow thorough / rigid processes to ensure the business gets exactly what they want and need.
#2 Super Team Solution: Build a team who deeply understand the business and the technology domain so well they can complete each other’s sentences.

Approach #1 is fraught with slow moving, high cost projects filled with red tape. Approach #2 may work for a while but will end up building silos in the organization and stove pipe solutions because each Super Team will focus on their domain and their set of solutions and not necessarily think cross-Super Team.

The art here is KNOWING WHEN to apply the right approach. There will be projects that require very detailed requirements (strong process) and there may be projects that require you to “fly the pirate flag” and build a temporary super team but, i’d bet the majority of projects just need a little extra common sense.

The same common sense required to understand when to flush out a requirement because of a potential gap. Everyone on the project team should be able to do this but Architects need to be particularly good at spotting gaps. Business Analysts are heads down in the requirements and the Development team may already be thinking in the solution space but the architect should be considering broader implications to the application, data or technical landscape and need ensure that expectation gaps are clarified.

To minimize expectation gaps:
1. Hire strong people who will take initiative and cover for each other in case a hand-off is not clean.
2. Consider agile-like processes so the business can see the final deliverable a little at a time.
And look at the members of the core team. Just like installing that front door, if they don't have at least conceptual understanding of how the business intends to use the new deliverable and don't have experience in installing it...you might want to find some different carpenters.

Do ERP projects face more Implicit Requirements challenges than Custom Development (Microsoft, Java) project? What are good examples of Implicit Requirements to share?

red door

Make Vendor Visits More Valuable

noreply@blogger.com (Mike Marshall) — Thu, 21 Oct 2010 02:22:00 +0000

Vendor visit day rolls around every once in a while. A vendor who believes he has the perfect product to fit perfectly into our enterprise shows up at our door. Rarely does he actually have a perfect product, nor does it fit perfectly, but we try to be as polite as possible and give them their moment bathed in the projector’s lamplight. Even though it often seems otherwise, there are a lot of ways you can benefit from these meetings.

When I sit through vendor presentations, I try to take a hard look at the product. I use that examination to not only illuminate the vendors stuff, but also to contrast what they have done with our own systems. Here are some questions that I consider.

Is the product ready for prime time?

Too often vendor products are pushed out too early. I understand that they have to do this. “Shipping” is the first feature that you should include in any product design. Nonetheless as a prospective buyer, you have to validate that the product is mature enough for deployment in your world. If it is not mature, it may be brand new. Have they positioned their solution differently then other competitors or your own solutions? If so, can you gain some fresh insights from their approaches?

Is it built using composite packages that we may be able to use separately?

Maybe, the product in its entirety does not really meet your needs, but are there individual components that could be leveraged separately? If so, are there other vendors that offer just those singular components? Maybe, you should talk to them.

If there are separate packages, do they split along your business process lines?

Do their separate packages align with your business processes like accounting, order entry, inventory management, or invoicing? If so, this leads to even more possibility that you maybe able to re-purpose a package. If not, does their functional alignment make more sense than the way your processes are aligned or related?

Have they leveraged or OEM’d any products that you could leverage?

Looking under the covers what do you see? If major segments of their product are built on top of other vendors foundational products, maybe you should be talking to the foundation vendor instead.

Is there any concept or approach in their product that you can steal, adapt, or copy?

Steve Jobs said, “We’ve always been shameless about stealing other people’s ideas”. Hey! Great artists still steal. As long as you can stay within your legal restrictions and organizational commitments, go ahead and plunder and pillage. There is no shame in that.

Too often, our busy schedule overrides the meetings and gives us convenient excuses to ignore vendor visit day. Given the chance, though, you may be able to take advantage of an opportunity to consider broader topics and more strategic designs -- and if you happen to like the vendor’s new product, consider that a bonus.

Are there questions that you ask on Vendor Visit Day? Let us know below in the comments.

photo:Pablo Maroñas

Get-It-Done Guy's 9 Steps to Work Less and Do More

noreply@blogger.com (Mike Marshall) — Sat, 09 Oct 2010 22:34:00 +0000

The days are getting shorter in Ohio and it’s about time to put away the lawnmower and get my cozy book corner re-established. The only issue is that I can't seem to find enough time to read. My productivity needs a little shot in the arm.

As luck would have it, I got my hands on a copy of “Get-It-Done Guy’s 9 Steps to Work Less and Do More” by Stever Robbins. For those of you who don’t know him, Stever Robbins hosts a Top-10 Get-It-Done Guy productivity podcast. Stever holds degrees from Harvard Business School and MIT, has written for Entrepreneur.com and The Harvard Business Review, and is endorsed by guys like Chris Brogan (Trust Agents) and Keith Ferrazzi (Never Eat Alone). So the guy has some chops.

I hoped that this book could deliver on it’s “Work Less and Do More” promise. I wasn’t disappointed. Here is what I liked:

It's Not a “Snoozer”
Forget about it being a dry dissertation on efficiency. Fans of Robbins’ podcast already know this, but Stever’s a pretty funny guy. I found myself chuckling on page after page. A personal productivity book is rarely a “laugh out loud hit of the summer”, but Stever throws in enough zombie, robot, and monkey imagery to keep things moving along. He has a degree in Computer Science -- so he’s one of us, and he has our sense of humor.

It Offers Concrete Suggestions
Many times productivity books stay too far in the “general”. Where a bad book says... “Stay focused on the things that really matter.”, this book gives you very precise instructions on how you can do that. It gives you steps and methods that get you where you want to be. Several new and creative suggestions comes with each step so you can attack your time wasters head on.

It Helped Me Immediately
As a software architect, interruptions and distractions can destroy your focus. Stever suggests to designate days of the week as “Focus Days” He further suggest setting up “Administrative Days” to handle all those little administrative distractions at once. I went back to work the next day and scheduled an all day event on my calendar on Friday’s called “Focus Day”. I marked Monday’s on my calendar as “Administrative Day”. Both types of tasks need to get done, but now there’s a place for each. I stop worrying about getting enough focus time and administrative time which eliminates the worst distraction of them all -- worrying. Nice.

Add it to your list
Creative tips and concrete examples for each of his 9 steps -- delivered in a humorous fashion. I’d say that this book is the best I’ve read on this topic in quite some time. You should order a copy, and put it on the top of your stack in your own cozy book corner.

What else are you reading? Let us know in the comments below.

One Year!

noreply@blogger.com (Mike Marshall) — Thu, 30 Sep 2010 23:07:00 +0000

This week The Politics of Design celebrates its one year anniversary.

Thank You!

If you could take an extra minute today, we'd really appreciate it if you tell us how we're doing. Are there improvements you'd like to see? Share them. Are there subjects you'd like to discuss? Let us know. Do you have a favorite post? We'd love to know which. Please use the comment form below for feedback or share something about yourself.

We've enjoyed ourselves and learned a lot in a year. We appreciate each of you taking the time to drop by. We invite you to review our archives for articles that you might have missed.

We'll take your feedback, and try to incorporate it into the site in the upcoming weeks. We'll continue to try to publish interesting and original viewpoints that focus on software architecture, organizational culture, technology innovation, and what happens when those three things collide.

Thanks, again!

Mike Alvarez & Mike Marshall

photo:Mykl Roventine

The Desire for a Service Oriented Architecture ROI

noreply@blogger.com (Mike Marshall) — Thu, 23 Sep 2010 02:21:00 +0000

We’ve been looking for the ROI model for a service-oriented architecture for a long time. There are hundreds, if not thousands, of articles on the web like this one, this one, and this one. I even wrote one here. If SOA is so good, why can't anyone write down exactly how and when it will pay us back?

Seems like over the past few years or so, Information Technology has continually run into this "ironclad ROI requirement". Every concept or new idea, no matter its size, is challenged to show a measurable ROI -- usually at its earliest inception.

We're asked to quantify the benefits of our new solutions -- and no soft benefits, please. You need to show hard benefits, with real dollars, and they need to be documented in that business case spreadsheet that we always use. You know the one, right?

I've been reading Linchpin by Seth Godin. It's good. Like most of Seth's books, it challenges you to look at things from new perspectives.

Here's one such thought from page 96.

"The digitization of work (measurement, Internet connection, mechanization) makes typical MBAs very happy. This is the sort of thing you can put in a spreadsheet. The challenge is that all your competitors are using the same spreadsheet, so your opportunity for quantum growth and significant market advantage is tiny.

The easier it is to quantify, the less it's worth."

That's a strong message.

If your latest architectural design has such an obvious ROI that it can be shown in a simple spreadsheet somewhere, are you really creating something "truly great"? And, if you can't mark the exact date on the office calendar when your investment will break even, does that mean it should be killed? I don’t think so...

Maybe, we should reconsider this relentless focus on an architectural ROI. Thanks, Seth.

Is the desire for an ironclad ROI holding your project back? Should it? Let us know in the comments below.

photo: Erica Marshall

Any Color You Want...

noreply@blogger.com (Mike Marshall) — Tue, 14 Sep 2010 13:00:00 +0000

Users love color. So much so, that they're willing to solve almost any problem by applying a color to it. When they need to understand that one row in a grid is slightly different, they want to color code it. If it's positive, make it blue; negative, make it red. If the error is bad, make the text yellow. If the error is really bad, make the text red, and if the error is really, really bad, make the text hot pink!! ...[sigh]

I like color. I do. Nothing gets more depressing than sitting in front of a gray on gray workspace day after day. In those situations where things are mostly gray, a splash of color can draw a person's attention to a field in question. Color has its place, and color coding application data and capabilities is an OK practice if its done well and with a few things in mind.

I should explain that I'm not a user experience designer or anything like it. I'm just an architect who has spent a lot of time looking at interfaces that resemble Christmas wrapping paper and wondering how we let it get so bad. Here are my color guidelines. If you have any others, share them in the comments.

Never let color alone specify a point of data. If a date is expired, you can color code it, but somewhere else on the screen present the word "expired". If for some reason, your user's screen could only show black and white - would he still be able to use it? If so, you've got it right. If he has to depend on a background color of a text box to understand some data point, then you're missing the mark.

As many as 10% of your users are red-green color blind.

So if you have to color code something, don't pick red and green. In fact, red is bad for everything. Red is the toughest color to read, and neither white or black text on a red background will win you any awards from your users. I know red means "stop". I know red means "evil". I know. You still shouldn't use it.

Tie into your system's color schemes.

This lets your users customize their desktops so that they can align with the latest spring colors coming off the runways in Paris. This flexibility gives the users some control that they appreciate, and gets them out of the gray on gray world. Apple & Microsoft spent much more money than you ever will on color schemes. Leverage them.

A little goes a long way.

Keep the number of colors to a minimum. Choose 3 colors for "Information", "Warning", and "Error" - and stick with them. If you cannot relay the information with the use of one of these colors, then maybe the situation is more complex and you shouldn't rely on color coding at all. Take the time to offer other mechanisms to your users.

Use mock-ups to present alternatives.

In today's tools, there are hundreds of options beyond "color coding" to offer your users. They are asking for color coding because that is what they have experienced to this point. I've heard that Henry Ford once said "If I would have asked people what they wanted, they would have said faster horses." Collaborate with them on new and creative solutions beyond color.

Henry Ford, referencing his Model T automobile, also reportedly said "They can have it in any color, as long as its black." Henry was a pretty smart guy.

photo: Robert of Fairfax

The Book of Hebrews

noreply@blogger.com (Mike Marshall) — Tue, 07 Sep 2010 13:00:00 +0000

A long time ago, when I was just starting out, I had the opportunity to work with a very smart architect. I didn't appreciate it at the time, but he taught me so much about how to put together creative solutions. He always bit off more than he could chew, always overreached, always aspired to create something truly unique and incredibly powerful. In one session, feeling a little overwhelmed, I started to question that reach.

He had laid out something so advanced, so big, and so complex that I just couldn't fathom how we were going to put it all together. How would we do it well, and get it done by the deadline? So I asked, "How are we going to make this work?" He turned, smiled, and asked simply, "Are you familiar with the book of Hebrews?". I wasn't, so he taught me something else.

He was referring to Hebrews Chapter 11. Which begins:

"Now faith is the substance of things hoped for, the evidence of things not seen."

In large multi-phase projects, there are always challenges that are complete mysteries before you begin. These scary dark places can pull at your focus and weaken your confidence in your early designs. These "unknowns" always seem to distract the team. They are the source of continuing conjecture and debate. These discussions never push the project forward. They just continually lament the fact that you have risks in your project (all the good projects do!), and add fear, uncertainty, and doubt to your plans.

This smart architect knew that there existed a secret ingredient that can short-circuit this fear and wash away your uncertainties. There exists a single component to your meetings that can re-focus staff, and get them working on issues that they can resolve. The ingredient is "faith".

Have faith that you have assembled a strong team that CAN deliver the goods.

Have faith that these obstacles WILL eventually be overcome, or will melt away never having existed in the first place.

Have faith that if you make progress on the path each day, that path WILL lead to a viable endpoint.

Have faith that you WILL figure it out, you WILL find the answers, and you WILL deliver a good solution.

Once you have established your faith, you must instill this same faith in your project team. If a team doesn't have faith that it can deliver on its promises, this is an issue that needs to be resolved right away. A lack of faith in your efforts by your team members is a larger problem than all of those future uncertainties stacked on top of each other. Find your team's faith first, and the project will take care of itself.

And if at some point, your team begins to questions how you are going to put it all together, do it well, and get it done by the deadline -- tell them the same thing my old friend told me, "By faith..."

So, Are you familiar with the book of Hebrews? Let us know your thoughts in the comments.

photo: Thierry

Are You Breeding "Yes Men"?

noreply@blogger.com (Mike Marshall) — Tue, 31 Aug 2010 13:00:00 +0000

A "Yes Man" is the guy that no one wants in their organization. It's the guy that agrees with the boss and only says what the boss wants to hear. Bosses hate "Yes Men" -- or at least the good ones do. They never hire "Yes Men". They hire strong, confident people with their own opinions and the backbone to share them. This is how the boss ensures that he is building a stronger organization.

Strong bosses also challenge their subordinates assertions though, too. When the same confident project manager or an architect is explaining why a deadline cannot be met or a target cannot be achieved, the boss questions that assertion with a "Why not?" He asked for an explanation as to why the associate has deemed the objective unreachable. The boss tests the assertion from a few different angles with some probing questions.

This should be expected. This is what a good boss does. He validates positions and looks for alternatives to unexpected situations. He doesn't just accept the "No" answer, he wants to know "Why?".

But in many respects, this good management can breed a bad organizational behavior. You might be breeding "Yes Men".

A boss that pushes extraordinarily hard on the negative status reports and doesn't require the same level of explanation on the positive reports will ultimately coax his organization to deliver only good news.

When a manager hands the boss bad news, does the boss engage in a long discussion around alternatives and explanations? Sure, but if the manager had reported good news, would the boss have asked for the same level of support? Would the boss have asked for backup data to support the position that the project is on track or the budget numbers look good? Would he say, "I'm happy that things are on track, but can you help me understand what indications you have that things are going well?"

If he confronts the bad news with questions, but accepts the good news with a smile and a nod -- he's breeding "Yes Men".

Can Microsoft unseat BlackBerry in the Enterprise?

noreply@blogger.com (Mike Alvarez) — Sun, 15 Aug 2010 14:22:00 +0000

Previous PD posts covered Android and iPhone and this post rounds out our prognostication act with Microsoft and a little BlackBerry.

Microsoft is looking like the wildcard in the mobile market. Why? Because they have an incredible amount of leverage but we don’t know how they are going to apply it.

Microsoft commands over 90% of desktop OS market and have a thriving developer community. Microsoft’s Windows 7 has been a huge success. Interesting fact: Windows 7 has been gaining market share while Mac OS X has actually lost market share since the beginning of 2010.

65% of organizations chose Microsoft Exchange for email and collaboration. They have greater than 80% of the worker productivity market with their Office Suite. Microsoft’s Xbox 360 owns a considerable portion of the gaming console market as well.

Add all those market shares up and it spells…l-e-v-e-r-a-g-e.

However, Microsoft was late to the party with the web, they have not made much of a showing in the mobile market to date and they really missed the mark with the Kin.

The mobile market is changing rapidly and this could be the perfect time for Microsoft to unseat RIM. BlackBerry has been the mainstay of enterprise mobility for years but they have not kept up with the pace of change and, nothing against RIM, but BlackBerry’s leverage position is whittling down to their network and market share so they are little more than a wrapper around email and calendar which is a generally served up from Microsoft Exchange. The Torch is a good departure from the BlackBerrys currently on the market.

RIM reminds me of CompuServe who started the online business and owned the market but failed to adapt to the rapidly changing web-based world. RIMs network started when there were instability and gaps in coverage from other carriers and staying connected was a tremendous advantage while on the road.

This Microsoft unseating RIM prediction is really comes down to more of a desire to own a device that provides me seamless access to my enterprise tools such as email, calendar as well as collaboration tools such as Word and Excel and instant messaging. A world where my phone and desktop/laptop are linked (maybe via cloud) so I can grab that file I forgot to send to someone. Where I can travel to another location and my phone will provide me access to another laptop with my profile, settings and documents automatically synched. Where our SharePoint intranet has an out-of-the-box mobile consumable version.

Finally, I would also like this device to transcend enough into my personal world so I didn’t feel like I wanted to carry around 2 phones as soon as I left my building.

I know I am asking for a lot, but c’mon Microsoft, you have a bazillion developers out there. Surely this is something you could do in a handful of sprints. :)

Leverage points:
Enterprise Presence:

Dominate presence in the enterprise (Exchange, Office, OS, etc).

Strong corporate provisioning and distribution abilities. This is something Apple and Google don’t have.

Bing.

Weakness:
Execution:

Late to the game in the past and has not delivered compelling mobile solution to date.

Threats:
Google.

Google is going to own the personal productivity mass-market. Will Google continue to advance in the Enterprise?

Windows Phone 7 links:

Fresh Look
htc Windows Phone 7

Am I asking too much of Microsoft? Do you think RIM will rally and maintain its presence in the enterprise? Love to hear it.

Apple (iPhone) owns mobile media:

noreply@blogger.com (Mike Alvarez) — Thu, 29 Jul 2010 02:15:00 +0000

Prediction: Apple - iPhone to own rich media market:

You can't deny Apple's influence on many of the modern gadgets we use. Most of them are copies of or have been influenced by the iPod, iPhone, iPad. Apple gets UI better than anyone.

If user interface intuitiveness were graphed with “I don’t get it” on the left side and “WOW! that Rocks!” on the right we would see interfaces such as SAP and Lotus Notes on the left ending with many of the Apple products on the right. (For an entertaining thread on the worst interface ever, check out stackverflow.)

To test this theory, think about the last 3 people you heard brag about their phone. I'd bet they bagged about their iPhone or Android phone and Apple essentially defined the modern mobile market with the launch of the iPhone in 2007. Would Google have entered the mobile device market if it weren't for the iPhone?

Either way, Apple and Google are driving a gi-normous pie-shaped wedge into the mobile market with Android and iOS based phones chewing up about 40% of the smartphone market.

As our last posts indicates, I believe Android based phones will overtake iPhones as a percentage of the market. However, if Apple follows its premium strategy, they aren't competing for overall market share, rather dominance in the premium market. This smells like Mac vs PC all over again but this time Apple has a large first mover advantage.

Apple will maintain it's grip on the premium segment of the market by continuing to set the bar for a mobile experience. High performing, compact, fun to use devices with amazing screens (retina display) and seamless access to media (music, movies, podcasts, TV). These factors plus the iTunes conduit will result in Apple owning the majority of the premium device and mobile media markets.

Here's the breakdown:

Leverage points:
First mover advantage:

Apple essentially defined the SmartPhone 2.0 market and continue to lead. Many vendors are jumping into the fray but Apple has an advantage with a loyal following.

Control over the platform and good developer community in place:

This is a strength and a weakness for Apple. As an iPhone developer, I like knowing the screen dimensions I am dealing with not having to keep my eye on dozens of vendors entering the market and having this experience. As a parent I appreciate some of the control Apple has in place to filter out items I'd rather not have my children exposed to.

Tremendous presence in the media market:

(almost) Everyone uses iTunes for music and consumers trust Apple for purchases of music, videos, movies, games.

Weakness:
Closed and controlled:

As previously mentioned, strength and a weakness. The openness of the Android will naturally evolve and mature more rapidly providing a plethora of app choices to the consumer. However, Android may end up having some of the same challenges Microsoft PC users have with performance and instability issues because of this openness. i.e. as an Android phone owner, I am constantly killing apps that drain my battery.

Multi-device support:

If you want an Apple based phone, you are limited to one phone. No preference of slide out keyboards, no smaller or larger form factor. One size fits all.

Threats:
Google:

*IF* Apple focused on the premium market, their only competition will be the overlap between premium and mainstream which Google will own.

My opinion on Apple vs Google is: there is room for both but Google will own the majority of the overall market and Apple will have to determine if they should take on Google or stick to what works.

Next post: where does Microsoft fit in all this? Have an opinion to share? Love to hear it.

photo: iPhone

Android phones catch iPhones by Christmas 2010

noreply@blogger.com (Mike Alvarez) — Fri, 09 Jul 2010 04:21:00 +0000

Last week’s post focused on the level of impact mobile technologies will have on companies but if you are placing a bet in this rapidly shifting market, where do your turn? The iPhone is getting a ton of press but Android is coming on strong. RIM’s Black Berry still has the lion’s share of the business mobile market and, well, you can read the graph (top). comScore just released this yesterday. (Apple's numbers are pre-iPhone 4G)

My prediction is that Android-based phones will overtake iPhones as a share of the market between Christmas and 2010 New Years Eve. My co-blogging friend owes me a burrito if I am right. I believe this because I think the Android platform will be the leader in the “Personal Productivity” space.

By “Personal Productivity” I mean anything that make my personal (and sometimes work) life easier such as keeping up with personal emails, tweets, texts, facebook updates, directions to GrandMa’s house, to-do lists and reading about LeBron’s decision.

I have an HTC EVO and it is an amazing device. The Google Nav is awesome. I have widgets for all of my Gmail accounts, a POP email account, GTalk, and many other awesome features that have greatly simplified my life. You might wonder what this has over an iPhone and the advantage is the seamless integration with my life. I purchased the phone, walked out of Best Buy and my contacts were synched before I hit the parking lot and I received a meeting reminder by the time I walked back in the door. Awesome! Pure Personal Productivity brought to me mainly because I use many of the Google tools such as Gmail, Google Docs, Google Calendar, etc.

Here is my assessment of Android in the market:

Leverage points:
Google cloud services:

Gmail, Google Search, Google Maps, Google Docs, etc. These are amazing cloud based tools for personal or small business productivity but I don’t see medium to large enterprises leveraging any time soon.

Openness of platform and good developer community in place:

This could give Google a larger app Market than Apple’s App store but the real winner here will be the store with easy access to good apps, not just who has more apps.

Weakness:
Openness of platform:

Yes I think this is a strength and a weakness. From what I have seen of Google’s Market and Apple’s App Store, the openness of Google pushes the responsibility for censoring content to the user, or more importantly, the users parents. You are more likely to run into objectionable material on the Google based devices than the Apple based devices. This is not a matter of right or wrong, but a matter of preference.

Multi-device support:

Also a strength and a weakness. Multi-device support will result in consumers getting the device that fits their needs (various screen sizes, keyboards, form factors) but I believe this will lessen the experience for certain content such as movies, games and other rich media because the media will need to run on various devices with various screen sizes and various resolutions.

Threats:
Microsoft:

I don’t think Google mobile confrontation is with Apple or RIM but Microsoft. I will save the details for the Windows Mobile 7 post.

The next post will focus on one of the other players in this market and you’ll see while I really like the Android OS, I might be more of an Apple fan.

Got a better prediction than Google OS catches Apple OS by Christmas? Love to hear it.

The Mainstream Mobile Revolution

noreply@blogger.com (Mike Alvarez) — Sun, 27 Jun 2010 03:49:00 +0000

While mobile devices have been in integral part of the tech-savvy lives for some time, the availability, functionality and price point has driven these devices into the mainstream and into the hands of the average consumer.

This mass-market availability of mobile devices (and the software that comes along with them) is affecting how we conduct business and how we consume/create information. I believe the Mainstream Mobile Revolution will have even greater impact on our personal and corporate lives than the Web did when it hit the mainstream in the ’90’s.

Reflect over the last 10 years and consider how much time and investment was allocated to (or influenced by) Web based technologies. It’s significant for both business and individual consumers. The Web changed how we pay bills, do our taxes, communicate, watch “TV”, interact with our consumers, sell our products, integrate with partners, etc, etc, etc.

Mobile technology is poised to have an even greater impact on our personal and corporate lives over the next 10 years...and here is why:

1. Technology & connectivity are an integral part of our lives. Ten years ago many were connecting to the internet through a clunky device called a modem! Today, we’re disappointed when we can’t find a Wi-Fi hotspot at a restaurant. Fast forward 10 years and it will almost be unheard of to be without connectivity.

2. Lower barrier to entry. Today I can get connected through cable, DSL or stealing my neighbors Wi-Fi. :) These methods require physical infrastructure to my house. Mobile follows me wherever I go. Couple the low barrier to entry with the demand from the emerging BRIC (Brazil, Russia, India, China) countries we have a tremendous catalyst for growth.

3.Digital Natives are going to define the mobile revolution over the next 10 years. A bunch of grey-beards defined and designed the internet revolution. We grew up before texting, IM, email and the web. Imagine how a generation will define the mobile revolution given they were born and somewhat defined by digital communications!!

4. The demand for immediate access to information. He who knows (or shows up in a search) first, wins! Gone are the days of yellow pages, paper maps, newspapers, etc. Everything you need is in your phone! Web access through a desktop was great but immediate access through my HTC EVO is even better!!!

The Mobile Revolution has been around for some time but hasn’t hit the mainstream until the past couple years. Many companies are still trying to determine how to leverage this matured medium which could include more than just creating an iPhone App.

Some corporations caught the wave early on but I bet the majority are still playing catch up. Maybe you can help me fill in the blanks: What percentage if your companies decision makers are leveraging mobile devices in their business and personal lives (outside of BlackBerry email and calendar)? How many of your top-level IT management know the difference between a platform specific app (iPhone App, Android App, etc) and a mobile Web App? Do you understand how your company is going to take advantage of a technology that could shape your business to a larger degree than the Web did over the next 5-10 years? Are your backend systems ready to integrate with mobile clients? Is your call center ready to handle the questions from mobile users?

I’d love to hear your answers to these questions. Is your company well positioned, in need of a wake-up call or moving forward in fast-follower-fashion?

Next week’s post will ponder who will win the mobile device wars. Apple? Google? RIM? And where is Microsoft in this mix? No one knows for sure but I have some thoughts to share.

photo: Mobile Revolution

Governance: Influence (Part 3 of 3)

noreply@blogger.com (Mike Marshall) — Tue, 08 Jun 2010 14:00:00 +0000

In the first two sections, we talked about what governance is (Governance - A Definition (Part 1 of 3)), and the necessity of having an enforcement mechanism (Governance: Enforcement (Part 2 of 3)). This section covers the areas where an enforcement mechanism can't be applied.

No matter how tight your process and how strong your enforcement mechanism is, there will always be gray areas. Any guideline, rule, policy, or law always is open for interpretation. Every guideline has exceptions, and not all decisions are made based on architecture's direction alone. No enforcement mechanism can be that smart. So, how do you handle the request for exceptions from a developer that is up against the mother of all deadlines?

Inflexibility sets you back.

Inflexibility, in any exchange between two parties, will extend the amount of time spent in discussion. As much as you hate to compromise on a point, you must weigh the value of compliance against the good will lost for your bullheadedness. If you see your solution as the only acceptable one over and over, the time-crunched developer will see just opening the discussion as too costly, and will avoid you and your governance in any way he can. You cannot become the "Department that just says "No". If you do, your uncompromising demands just leads to your guidelines being ignored and circumvented more times than if you had just granted every exception requested.

Collaboration moves you forward.

Collaboratively working with the development teams is the only solution for effectively managing cases that fall outside of your basic enforcement rules. When exceptions come up, assess them with regards to your most strategic plans and pick your battles selectively. Only dig your heels in when you have strong proof that any other direction would seriously compromise one of your primary objectives. Collaborating with your development teams builds a shared sense of ownership and responsibility for the delivered solution. Working closely with the team through these issues also gives you a chance to reinforce your primary objectives and explain why your rules and guidelines are set up the way they are.

photo: Thomas Hawk

Governance: Enforcement (Part 2 of 3)

noreply@blogger.com (Mike Marshall) — Tue, 01 Jun 2010 14:00:00 +0000

In the last section, Governance - A Definition (Part 1 of 3), we explained that governance is a process for setting out rules and guidelines that should be followed. For the DMV, these rules and guidelines are the driver's license and vehicle registration laws. For your architecture team, these rules and guidelines are the architectural strategies and best practices. We also said that all things being equal, everyone understands why these rules exists and agrees to follow them. But do they always follow them? Why not?

Whether you work for the Department of Motor Vehicles or are a member of your Architectural Governance Group, you hear a lot of excuses.

You hear drivers say things like, "Standing in line takes too long!" or "Registrations are too expensive!" People procrastinate and complain - and ultimately the only real reason they end up registering their vehicles and renewing their driver's license is the fear of being caught and fined by the police. Even with a public consensus that the DMV's rules and regulations are necessary, true enforcement is the only thing that keeps us all on the right track.

Architectural governance is a very similar case. Even though, developers will universally agree that the architectural guidelines are fair, necessary, and reasonable. Only a true enforcement mechanism will keep them implementing systems along these guidelines. Outside influences like close deadlines and short budgets are always going to push developers to code something short of the prescribed solution. In today's resource-constrained world, a governance process must have a strong enforcement mechanism to be effective

In architectural governance, there are two types of enforcement, and one is much better than the other in the architectural arena.

The Speed Trap.

This enforcement mechanism is the post-violation type. It waits for someone to do something wrong and then penalizes them. It's foundation is set in the "blame game", and it breeds contempt for the architectural governance team, and unless the fines are big enough (like maybe getting someone fired!), it rarely works. What you end up with is people who are asking for forgiveness instead of permission, a long list of transgressions with meaningless penalties attached to them, and worst yet, the violations result in bad systems in production.

The Parking Gate.

This mechanism prevents violations before it happens. It is built on some (usually mechanical) prevention mechanism in your software configuration management process that prevents a team from bypassing an architectural guideline. The step must be completed prior to being able to deploy your solutions to production, and thus violations can only occur in emergencies and then only with visibility. Ultimately, these mechanisms are predictable and are accepted by the development teams as normal operating procedures.

Governance via the right enforcement mechanism keeps your architecture under control, but no enforcement mechanism can cover every situation. When that is the case, you'll need to govern through "Influence". That's covered next.

photo: Seattle Municipal Archives

Governance: A Definition (Part 1 of 3)

noreply@blogger.com (Mike Marshall) — Tue, 25 May 2010 14:00:00 +0000

The definition of "Governance" is often confusing. Put simply, "governance" is the process that "governs" your application landscapes and designs. To visualize this, think of a government department like the Department of Motor Vehicles. The DMV governs who is legally allowed to operate motor vehicles and which vehicles are allowed to be on the roads. By issuing driver's licenses and vehicle registrations, the DMV performs a process of governance.

In the DMV's case, the governed body is the drivers and vehicle owners. In your IT organization, the governed body is the group of developers that build systems. In both cases, the governed body is expected to adhere to the guidance of the governing board. Drivers follow the rules of the DMV. Developers follow the guidelines of the architecture teams.

Fair and Reasonable Rules

There are many reasons why we follow the rules of the DMV. We believe all drivers should complete the minimum amount of training necessary to safely operate a vehicle. Your commute would be dangerous if the drivers around you did not know the traffic laws. We believe having all vehicle owners pay a registration fee to support the costs of maintaining the streets and highways is fair. Everyone agree that these reasons make sense, and as a driving population, we agree with this approach.

In architecture, too, most developers will admit that architectural guidelines make sense. The basic approaches of component-based design and strongly-typed objects has been shown to create more reliable systems. These approaches have been around for a long time, and vetted and accepted by many experienced professionals. Everyone agrees about the "right way" to build a system.

So "Governance" is the process for establishing and ensuring the compliance with the architectural strategies and guidelines used by your organization. By following these strategies and guidelines the governing body helps to ensure better quality systems moving into production. Interestingly enough, everyone from executive management down to the line developer will agree to these strategies and principles. In your organization, you will be hard-pressed to find anyone who won't agree with the written rules and the reasons that those rules exist. So why do we need a governance process and a set of strategies and guidelines? We'll cover that in the next section: Governance - Enforcement.

photo: jamison

Conquering Far Off Lands

noreply@blogger.com (Mike Marshall) — Tue, 18 May 2010 14:00:00 +0000

Long-term strategic plans need to be developed to make sure you are keeping your eyes on the horizon and planning the advancement of your architectures. Taking on a new long-term direction can be thought of a starting a crusade. They'll be strategies developed, battles to wage and win, and undiscovered country to be explored. But, like any crusade, the success of your long range plans will rest on your ability to execute effectively. Here are the steps to take as you carry out your next campaign.

Develop your Battle Cries.

Before embarking on any large effort, you will need a strategy. A good set of guiding principles is the port from which your ships will sail. Without these, your goals are unclear and your efforts unfocused. An example of a guiding principle might be "All business systems will build on our strong accounting foundation and all transactions must leave the system in a balanced state". Develop as few guiding principles as possible while still effectively framing your desired end state.

Just as important as developing the strategy is communicating it to your legions such that they can easily execute them. Take the time to explain your strategy in detail, but your guiding principles need to be boiled down into smaller "battle cries". For example, your battle cry for the guiding principle above might be "The sun rises and sets in accounting!". The battle cry does not have to restate the principle. It just needs to be easily remembered and immediately remind the team of the original intent of the strategic statement.

Select Your Battlefields Carefully.

"Picking your battles" has always been good advice around the office, but which battles do you pick? The answer to this question is simple if you've laid out strong guiding principles. If the decision your trying to make revolves around one of your guiding principles, it's a battle that you want to fight. Following our example, if a project team member suggests building a transaction that's not solidly grounded in your accounting system, it's time to beat your plowshares into swords. On the other hand, if the question is not profoundly and directly related to your guiding principles, you probably need to let it pass. Too much attention paid to less important issues steals strength from your effort. Soldiers grow weary of constant conflict especially when the gains are too minor or too costly.

As a leader, let these less important decisions be made by those members of your team who emerge as your lieutenants. This fosters a collaborative environment where you can bend your vision to the directions of others. Further, it provides a sense of involvement and ownership among the ranks, and this community will be valuable when you find yourself engaged in larger battles.

Crown Kings in Conquered Lands.

Once your legions have reached a goal and finished an important phase in your crusade, you need to install leadership. Take your most effective lieutenant aside and explain to him that you will be depending on him to maintain the architecture that he helped create. Then, publicly let it be known that the new "king" will be governing the new kingdom. This breeds loyalty with your teams and also lets less experienced team members look forward to sharing in the successes some day.

Once your new king is installed and governing his new lands well, you'll be freed up to plan your next big effort, kick off your next big crusade, and expand the empire.

photo: swimfinfan

Designed to Fail? (part 4 of 4)

noreply@blogger.com (Mike Alvarez) — Wed, 12 May 2010 03:53:00 +0000

Part 1: Slaying the dragon.
Part 2: The dragon is still very much alive!
Part 3: Killing the Dragon…again.
Part 4: Making sure the Dragon does not come back to life.

As you enter the final phase of your journey, you know where you are going (system end state) and you have a good idea on how to get there. However, you have 2 hurdles you must clear in the final phase of your journey.

Hurdle 1: You must “sell” this end state to stakeholders.
Unless the system being replaced is catastrophically failing, your project will have to compete against other projects in your organization for funding and priority. In order to compete, you need to sell this initiative. An obvious consideration is ensuring your not too techy in your sell to the stakeholders but you should also consider who you need to sell to. In Sell the Center 60 Mike Marshall outlines the difference between success and failure in your selling strategy.

Hurdle 2: Ensure the “people” and “process” elements in the equation change with the “technology”.
...
Many organizations make the mistake of buying or building something new with the promise of greater efficiency but no real tangible change in the “people” or “process” quadrants of the equation to ensure this problem does not happen again. The reality is, the problem won't manifest itself for 3+ years and the folks who implemented it may have moved on to other priorities and you have Designed to Fail situation once again.

Your original architecture will be forced to change. It should bend but not break. You should be very aware of when an enhancement, no matter how small, goes outside the patterns and structure you initially established. Some people call this Governance. But the G-word falls flat in many organizations who like to move rapidly.

Make sure you review How to Fail at Service Governance for some good “hindsight perspective” on governance.

In order to deliver on the expectations of this system you should reflect upon the skill set of the team and their ability to support the architecture and governance process outlines above.

You will need to consider certain inexorable attributes of your team that conflict with your future state. i.e. are the seats on the bus filled with the right people? Measure them against the Architects Core Values series.

Do you relate this fable to any events in your career?

photo: Slayed Dragon

Designed to Fail? (part 3 of 4)

noreply@blogger.com (Mike Alvarez) — Wed, 05 May 2010 03:38:00 +0000

Part 1: Slaying the dragon.
Part 2: The dragon is still very much alive!

Part 3: Killing the Dragon…again.
The challenges you faced in building the system (see Part 1) seem so trivial to the challenges you face now. Now you are faced with years of legacy complexity to unwind as well as negative perceptions from your business.

How are you going to handle data conversion? What about all the business rules strewn throughout various modules and all of the end-user training and reports that have to change as a result of the overhaul of this system?

You realize the most significant challenges in IT aren't necessarily the most glamorous.

Significant challenges come in the shape of:
A: Ensuring the systems you build, maintain their value to the business over time.
B: The easy part in replacing a system is picking the “right end state”. Understanding how to get there and dealing with legacy complexity, is the hard part.

The better you are at “A”, the less you have to exercise “B”.

The painful reality is many systems grow organically and suffer from the symptoms outlined in Part 2 and need to be replaced.

Picking the right solution is the easy part but influencing a broad group of IT and business users to migrate to this end point is challenging.

You decide to do the following as you migrate toward you end state:
1.Since you engaged a software / service vendor, you make sure they don't glaze over legacy muck. Many “right solutions” fail to launch because the “blast radius” of change was too large.

2.You decide to Fun Size Your Design because the scope of change is overwhelming.

3.You take on the role of Playing Devils Advocate for how to test the future state.

In the final stage, you contemplate how to ensure the dragon does not come back to life...

photo: Dragon

Designed to Fail? (part 2 of 4)

noreply@blogger.com (Mike Alvarez) — Tue, 27 Apr 2010 03:58:00 +0000

Part 1: Slaying the dragon.

Part 2: The dragon is still very much alive!

"How did it get to be such a mess” is the first thought that rattles through your head. The next is wondering who messed up the architecture and system you worked so hard to put in place.

...

How did this happen?
- Did we build the wrong solution? No, the business tested it during UAT and signed off that it met their requirements.

- Did we use the wrong technology or package? No, that same technology works just fine in other installations.

- Was your architecture comprised? Not really. Some compromises were made over time in order to meet cost or time to market but those small gaps couldn’t lead here, could they?

- Did your team just 'lift their heads off the ball' and lose focus over time? Most of initial team (including yourself) ended up focusing on new challenges and you did outsource some of your development tasks but the new team should have maintained your initial vision.

- Did urgent changes result in sub-optimal enhancements against your initial architecture? Somewhat, but they were small. The Project Manager and Developer both said they were small, just a couple extra fields.

- Did the development team allow the business to blend the use cases supported by the system because it was so successful initially? Yes, the tool worked so well for one business process that the team also allowed it to support neighbor-system use cases as well. Reuse is good, right?

These are all valid questions. In order to assess them you find yourself steeped in endless conversations of blame assessment and trying to measure the path you didn’t take. You don’t have all the answers but your perception of your system decayed as rapidly as Tiger Wood’s public image. One thing is clear, the business’ Dragon is still very much alive and actually may be larger than ever.

You don’t have the answers you need but you regain your resolve and determine the phase you are in is focused on the past and this won’t get you anywhere. You decide it is important to move through this phase quickly and without leaving too many dead bodies behind. Beating each other up over what happened in the past is useless.

Here is what you decide:
1. Gather data to determine what failed. Where were the gaps? Exactly what is "too slow"? Are there salvageable portions of your system?

2. Avoid the blame game. You don’t have time to gather empirical evidence for all of the questions above so you will have to rely on opinion in certain cases. Try to avoid the blame game, which will be difficult because team members are personally connected and identify themselves with this system. After all, they’ve focused the past few years of their career successfully supporting the business with enhancements to this system.

3. Look for some external perspective. Sometimes a fresh pair of eyes can see something no one else can.

Then move on to phase 3...

photo: the Dragon

Designed to fail? (part 1 of 4)

noreply@blogger.com (Mike Alvarez) — Tue, 20 Apr 2010 00:59:00 +0000

This 4-part post walks through a fictitious (but all too realistic) reflection of how perfectly good systems go bad.

Part 1: Slaying the dragon.
Your business approaches you with an urgent need. Many C-Level conversations result in an agreed to business direction and an allocation of $3 Million IT dollars in order to address their needs and better position the company for success. You leave the final conversations with a great deal of purpose in your mind and urgency in your step. The business has clearly identified the ‘Dragon to Slay’ and *you* are right on the front line.

Fast forward several years and that moment has faded like a distant memory. All of the urgency, the clarity in direction and the refined architecture sketched out on white boards. You helped build the A-Team of players to implement this new mission critical system. You and your team were on “center stage” and filled months worth of the C-Level meetings with progress updates and you personally beamed with pride as your system performed exactly as you hoped it would as it gained increasing adoption across the enterprise. You were successful in slaying the dragon!

It seems so impossible with all of that clarity in direction, all of that urgency, all of that money, that you are now, several years later, sitting at the table with highly-polished representatives from an external vendor’s sales team, listening to them articulate how their new system will solve all of the problems with the current system that is now “too complex, too slow, cost too much to maintain and needs replaced”...which is exactly how your conversations sounded several years ago except you were on the other side of the table.

Apparently, “Franken-Dragon” has come back to life.

Does this sound familiar? Which seat were you in during this conversation?

Part 2: The dragon is still very much alive!

photo: Slay the Dragon

Can I borrow your jet?

noreply@blogger.com (Mike Alvarez) — Thu, 01 Apr 2010 04:27:00 +0000

I recently traveled South for a little R&R. The flight, and a recent conversation with a contact who works for a fractional airplane ownership company, had me thinking about how awesome it would be to pick up and travel wherever, and whenever, I want. Then I woke up and realized I am much closer to affording fractional ownership of a paper airplane rather than a multi-million dollar aircraft.

Maybe someone would let me borrow their jet?

I want to use it in the same way they do...to get from Point A to Point B. I can’t afford a true portion of a multi-million dollar jet but I might be able to pay for some of the fuel costs.

This idea sounds insane because I am trying to obtain a service without paying for my fair share of the service. The reality is there are costs to maintain the plane, airport fees, staff to fly the plane, service the plane, clean the plane, manage the availability of the plane, etc.

This seems very clear when talking about an airplane but we allow this to happen frequently within IT and the impact is much less obvious.

Multi-million dollar IT systems are common for mid to large sized companies. Our job in IT is to manage the fleet (systems). The justification and implementation for these systems are generally well planned and executed but once the plane...er, I mean...system is in production we let anyone use it without understanding the incremental cost and “wear and tear” of the additional use.

Think of your business users as different fractional owners of the jet. Your job is to ensure the jet is secure and performs well for all of the jets owners. Business users are very creative and will approach you to use the jet in creative ways that seem entirely reasonable in the IT world but absolutely preposterous in the physical (airplane) world. They ask for changes to a system to meet their specific need but they don’t want to pay for the full fractional cost of the system.

This seems so obvious with a physical item like a plane but IT is perceived as a barrier when raising these concerns for a system because technology makes it SEEM so easy. i.e. I can’t “copy / paste” an airplane but the reality is, many of the same challenges still exist between a physical asset like a plane and a virtual one like a system.

You would not allow an owner of a plane to skip routine maintenance because she wants her long term costs to be cheaper. It would just pass the cost on to other fractional owners. You can’t let one owner land in a grassy field to avoid airport fees. Logic dictates necessary elements in maintaining an efficient operation. An operation that works for all users, over time, rather than satisfying the instant gratification of a single owner.

So the next time you (“you” being the Project Manager, Developer or the Architect) find yourself in the position where you feel like you are being asked to jettison some unused seats for one flight, understand how it meets the need of a particular business owner but may impact other owners who own a vested interest in this system and ask yourself if they are truly supporting their fair share of the asset.

You might make that owner happy that particular day but eventually this behavior will result in all of your owners leaving with you holding the keys to a pretty useless plane and many other vendors lining up to sell your business another multi-million dollar plane that will address all of the issues of the one you just allowed to get messed up.

Sound familiar? Disagree? Please let me know by commenting below.

photo: Plane