The Politics of Design

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?

Last weekend I was reminded of 3 things:

1. 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.
2. Streaming media rocks!
3. Product integration between devices we use is the critical success factor in market share for Apple, Google and Microsoft.

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??

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.

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?

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.

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?

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.

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

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.

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

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.