The Technology Edge

Mobile Web Development Tips and Tricks

2010-02-26T14:25:00.008-06:00

A brief presentation on 30 tips around context, performance, design, security and portability of mobile web applications.

Slides	Corresponding Video (15 minute version)

View more presentations from J Schwan

Augmented Reality - Unleash Your Enterprise's Sixth Sense

2010-02-23T21:54:00.015-06:00

Augmented Reality might seem like a futuristic word but the reality is it's a technology that is already available and the opportunities for the enterprise are endless. Now is the time to start thinking about how you can leverage it to better your corporation. This blog is going to give you some baseline education, some examples and ideas on how you can leverage this technology today.

First, what is it? Wikipedia defines it well but the jist is this: Augmented Reality is a combined view of the physical real-world with information from the virtual world (in most cases, the internet).

Yelp's "Monocle" functionality on the iPhone is a great practical example. It combines the iPhone's camera view, overlayed with a listing of local restaurants and bars. The information presented is based on the phone's GPS coordinates as well as it's compass reading. The short YouTube video below demonstrates this for those who haven't seen it.

Pretty cool, eh? This concept isn't unlike the yellow, First Down line we're used to seeing in NFL games. The line doesn't exist, it augments the physical view of the field based on information about the game in progress.

With the maturation of mobile devices, Augmented Reality (AR) offers additional information that you normally would not have available with your biological 5 senses. Combining a mobile device's eyes (camera), ears (microphone), location (GPS), orientation (compass), movement (accelerometer) and brain (data connection to the internet) a mobile device can provide you with essentially, a 6th sense.

And it doesn't have to be visual. The Shazam mobile application utilizes the phone's microphone (ears) and listens for music playing in the background. It then sends that information to the internet, which performs audio-recognition to determine the name of the song playing. The app then provides the user with the song title, artist, discography information and upcoming concert dates of the artist (based on your location of course).

Examples for the Enterprise

Now let's think of some examples for the enterprise. Let's say you're a sales representative visiting a client. As you near their building, you pull up your phone and launch your mobile AR-powered CRM app. The phone recognizes the building you are standing in front of and overlays it's view with a list of all customers who work in the building. You select your customer's name and are immediately presented with a consolidated view of relevant customer data, including recent call logs from your call center.
Perhaps you're heading to a meeting in your own building and the conference room you have scheduled is occupied. Do you barge in or wait it out? It really depends on who is on the other side of the door doesn't it? You pull out your phone, launch your conference room scheduling app and hold up the camera to the conference room name/number on the door. The app utilizes your phone's location and image recognition on the conference room sign, immediately presenting you with information on the current meeting taking place, including current participants. If you want to see other options, you click a button and it brings up other available conference rooms on the floor. You select one and it books your new reservation.
Perhaps you're in the corporate real estate group doing some location prospecting. You come upon a vacant building. Bringing up your AR-Powered Real Estate asset management application. It recognizes your location and provides you with a mash up of average lease rates/sq foot for the area, vacancy rates, demographic information about the population, etc.
There's a great app that already exists called RedLaser that uses the phone's camera to scan bar codes and presents the user with alternative merchants that sell the product on Google Product Search. Think about the applications for the retail industry with the availability of simple (cheap) bar code scanning functionality!

The point of AR is to be able to make decisions real-time. Historically, being on-line means you're off-life. You have to stop whatever it is you are doing and get to a computer, a computer which is incognizant of the world around you, to pull information about purchases, deals, hires, dates, etc. With AR, On-line no longer means on a computer. It means you're just "on". Imagine if you had the breadth of information available on the internet and your intranet with you all the time, everywhere you were, without a whole lot of squinty thumb typing and without any waiting. That is augmented reality.

Want some good news? It isn't that hard to build this stuff. The major smartphone's SDKs do most of the work in pulling the phone's "senses" information for you. That info combined with some open source image recognition projects, relatively commoditized OCR technology and your company's existing web services and ERP data stores, leaves only one question. What don't you want to do?

You know I love your comments. Share some ideas for the enterprise below and follow this blog. As we build these AR apps we'll be posting best practices, tips and tricks along the way.

Cloud Computing: Testing Microsoft Azure and Amazon's EC2 Economically

2010-01-15T15:40:00.006-06:00

This blog was guest written by Greg Hubbard. Greg is the Director of Application Development for Q Interactive, a Chicago based digital marketing services company.

When the resistance to technology innovation is discussed, the resistance is usually given the face of the mythical pointy haired boss, the management, finance or business person that “just does not understand!” While this can be the case, sometimes the resistance actually comes from within Information Technology and it should not. IT should be the entity thinking “well, let’s take a look…” While I do not advocate running around trying every new thing that comes along and throwing large sums of money at it in the process, I do promote looking at things in ways that are inexpensive in time and capital commitment. To that end, I use a three step process for trying out a new technology:

1. Find a way to try it out with minimal time and budget impact.
2. Discuss my experience in a large community.
3. Try it again.

Read the rest at ComputerWorld.com...

Situational Applications - Build for Today be Ready for Tomorrow

2010-01-04T14:02:00.003-06:00

Today I want to talk to you about the concept of "situational applications". The term is relatively new, but the concept is not. The concept is KISS (Keep It Simple, Stupid).

First let's define a situational application: "A situational application is 'good enough' software created for a small group of users with specific needs. . . as the requirements of a small team using the application change, the situational application also continues to evolve to accommodate these changes."

Many of the best applications begin as situational. For example, SMTP, which is the standard protocol for sending email, was initially developed as a simple way to send electronic messages, after the introduction of many bloated formats (including Mail Box Protocol and FTP Mail). Many early internet providers found these original protocols, although comprehensive, too complicated to implement. SMTP, which stands for Simple Mail Transfer Protocol, was developed as a simple way to send text-based messages from point A to point B. The simplicity of the framework caught hold, ultimately became the standard, and has since been enhanced with the features you know as an e-mail user.

Web services are another great example. The original vision manifested as Simple Object Access Protocol (SOAP), which was a comprehensive, complex protocol for allowing different systems to talk to one another. Ultimately, SOAP grew in comprehensiveness and complexity. As a result, Representational State Transfer (REST), a simple protocol that does the same thing as SOAP but without all the bells and whistles, was developed. The result is that REST has taken hold as the preferred standard. REST has continued to evolve to meet additional needs as they gain traction, but its evolution is organic, not forced.

I've had the opportunity to build a lot of new software products for great companies. And the more applications I build, the more I realize that most (if not all) of them are in fact, situational, and should be treated as such. Instead of trying to build the end-all-be-all in release 1, I've found we're more successful successful if we build an application that can addresses the core business problem, and getting it out into the user community quickly. Ultimately, the user community will drive the direction of the application. If a core need is met quickly, the app will be used; and if the app is friendly and appealing enough, users will want to give ideas on how it can continue to make their lives/jobs easier. In all of my years building applications, the most time-tested and well received, have inevitably started by simply solving a "situational" problem. Over time, they have become much more than that, but they all started with a laser focus.

If you are a product manager (or if you work for one) remember to Keep It Simple. Get the product out early and request feedback from users often. Use Agile Software Product Development to get that first release out quickly. The methodology lends itself to this approach. Stay focused on business value and work to achieve it as quickly as possible. Do not try to solve every problem for everyone right away, instead solve the BIG problem for everyone first. Everyone will line up behind you and your product after that to take care of the small stuff.

Please use the comments below to share ways that you Keep It Simple in your software product development, or share your experiences of how your 'situational applications' have become THE application because of laser focus on solving real business problems.

As always, thanks for reading.

-J

Whoa. . .this post was picked up by CIO.com.

Sometimes a Stalemate is a Win

2009-12-16T17:03:00.023-06:00

This story has nothing to do with technology. It is a life lesson I wanted to share.

When I was 12 years old I joined the Benjamin Middle School chess club. OK, OK, stop laughing. We would meet weekly after school to play chess and every month, play in tournaments against other schools. I'm not a great chess player, but I've always loved the game. Chess is one of the only games where there is nothing left to chance. There are no cards, no dice. It doesn't matter if you're the richest or the poorest, the luckiest or the unluckiest dude in the world. At the beginning of the game, the playing field is completely even.

In my first tournament I was playing another kid from a neighboring school. We were both beginners and pretty evenly matched, so the game took quite a long time. We were huddled up in a corner and it appeared no one was paying much attention to us. As the game progressed I found I had my opponent on the ropes. I was chasing his King down with a Bishop and a Rook and I could taste victory. I got his King cornered and after he studied his next move for awhile he looked up and said "Well that's it, you won, there's nowhere for me to go." I looked down at the board and realized he was right, but I didn't win. As he started packing up his pieces I said, "It's a stalemate. I didn't win because you're not in check. It's a tie." The kid was surprised and said, "I didn't know about that. That's cool!"

I put my pieces away and as I turned around to leave I almost bumped into our coach, Mr. Mason, who unbeknown to me, was standing behind me watching our match. He smiled at me and said, "I'm proud of you J.J."

"Proud of a stalemate?"

"No, not because of the stalemate. You could have taken that win to the judges table, that kid didn't know any better. But you told the truth, you were fair, and that builds character. For you, that stalemate is a win. Good job son."

I didn't think much of that exchange at the time. In my 12-year-old innocence I didn't think twice about making that call. Today, as a business owner and a family man, with a lot more to lose and a lot more people to take care of, I think about that day a lot. From time-to-time in my job, I'm confronted by others with a difference of opinion. I like to look at things objectively and most of the time, we can come to a mutual agreement with a quick, civil conversation. But sometimes, we just can't see eye-to-eye. When I hit one of those impasses, more often than not, my Italian blood kicks in. My ears get hot, my pride wells up, I start taking things personally and I lose focus.

When I feel that happening, I think about chess. I think about how objective the chess board is, how black and white the game is and how, out of all the permutations that could happen, there still is a possibility of coming to a draw. And then I think about that match when I was 12 years old. And I ask myself, "Am I being fair?" "If Mr. Mason was standing over my shoulder, would he still be proud?" The answer to that question always calms me down and dictates my next move. Whether it's standing my ground or handing some back.

It's a mantra I've come to embrace over the years. Sometimes you know you're right, and sometimes you realize you're wrong. But when you hit a stalemate, you always have your character to fall back on. And as long as you hold true to your character, a stalemate, is a win.

What Clark Griswold Taught Us About IT Production Deployments

2009-12-03T22:18:00.008-06:00

So "Christmas Vacation" is one of my all time favorite movies. My extended family and I watch it every year over the holidays, and no matter how many times I see it, it's always funny. And the older I get, the more I find it funny for different reasons.

Well I took it to a whole new (geeky) level tonight. After watching a clip of the movie a friend of mine posted on Facebook, I thought about how Clark's Christmas lights escapade reminded me of some of those production deployment horror stories from years past. Do you remember that night of production launch when something was not working and no one could figure out why, since you all tested the heck out of the thing for the 3 months prior and it definitively worked everywhere BUT production? So I sat on YouTube tonight adding some IT commentary to one of my favorite Christmas Vacation clips. Here you go and Merry Christmas!

4 Ways to Make your Packaged Application's Customizations Upgradeable

2009-11-15T08:03:00.023-06:00

Too often the Buy vs. Build argument get turned on its head when enterprises who buy a packaged solution to save money, end up spending more customizing it to fit their business' needs. When I say packaged here I am referring to things like ERPs, CRMs and even newer SaaS based applications. Customizing packaged apps is expensive since you often need proprietary skills and knowledge to make any changes. It gets even more expensive when it comes time to upgrade and many of those customizations need to be refactored or rewritten.

The reality is, no packaged app fits an organization like a glove, so some level of customization is expected. The blog below is meant to suggest some basic best practices for customizing packaged and SaaS applications.

1) Architect your Customizations - Encapsulate into Services
Too often developers don't think about architecting their customizations and instead, just slam some code into the packaged product. Customizations should be built as plugins, something that can, for the most part, stand on its own. I typically suggest encapsulating any business logic in an external REST service running on your enterprise's native application architecture (i.e. C#, Java, C++, PHP, etc.). Assuming it's a web based app, encapsulate custom presentation logic in an embeddable HTML or Javascript file. Ideally, embedding that file would be the only line of code that will need to be customized (plugged) into the packaged app. AJAX calls can be used to communicate between the custom presentation and the external services you write.

2) Avoid Use of Proprietary Customization Languages and APIs
Using proprietary languages for customization (i.e. Peoplecode, ABAP, etc.) will ultimately lead to pain later. Proprietary languages are typically procedural (or used that way) and aren't maturing at the same speed as industry standard languages are. It's often faster to build in external languages. The SDKs for the proprietary languages are evolving however, so upgrades usually require some level of refactoring. In general, what these languages were intended to be used for, and how they actually get used, varies widely. For basic data retrieval, processing logic and presentation, try to stay away from them. If you have to utilize a particular API because it contains some proprietary logic, encapsulate it in a single service, so you can minimize refactoring later.

3) Utilize Asynchronous Processing Where Possible
Customizations in packaged application often lead to performance problems in the app as a whole. The reason is packaged apps' application container's are often configured to run the native packaged application and basic customizations. The container's threading models are often not tuned to support large amounts of customized code (particularly those making calls to external systems). By utilizing the approach in number 1, you're utilizing the power of the browser to handle external calls to retrieve information. In cases when you need to make calls from the packaged application's server (i.e. to perform updates to external systems ), try to utilize asynchronous messaging for passing off requests. By utilizing a MOM like MSMQ or Websphere MQ, your taking a considerable amount of load off of the packaged application. You'll need to build some external services to handle any potential errors or issues that come out of the external updates, but this is a small price to pay compared to trying to debug issues occurring within the black box of a packaged app.

4) Keep the core-competency of the packaged app in mind
Too often business users will push to have more and more functionality layered into a packaged application. This bloats the packaged app, makes upgrades difficult and most importantly, limits reuse and accessibility of that functionality from other enterprise systems. By keeping custom functionality hosted outside of the packaged app, you're on your way to building a more service-orientated environment where the packaged app is a consumer of those services, and not the host of them. Portals and BPM applications can be used to string together those services (and those of the packaged app) into composite applications that are specific to a particular business. In general, use the packaged app for what you bought it for and don't try to turn it into something it is not.

Those are a couple of my thoughts, tell me about your experiences? How have you future-proofed your packaged app customizations?

This blog was also picked up by CIO.com

Utilizing Today's Technology to Formulate a Sixth Sense

2009-11-12T08:16:00.002-06:00

Really starts to get interesting and practical around the 4 minute mark. Very impressive. Enjoy!

4 Things to Think About: Identity Management for SaaS Apps

2009-11-03T18:05:00.006-06:00

Get Rid of the Submit Button

2009-10-30T23:46:00.005-05:00

I am starting a movement against the Submit Button. Perhaps you've seen it. It's the annoying button at the end of every web page you visit that requires a button-click before anything happens. It's also in every window that comes up in your operating system. Sometimes it says Submit or Enter or Go or Yeah! They slow users down, and honestly, with computing prowess nowadays, They are not necessary.

And I'm not talking about Confirmation buttons. Confirmation is different. That's an event we want the end-user to participate in. Enter information, confirm, submit. But the typical submit button is simply requiring the user to click another button after they are done with whatever it is they were doing in the first place, to make life easier for the developers of the site. This button is now irrelevant with today's technology.

How do you get rid of it? Use AJAX or a similar Rich Internet Application technology (i.e. Silverlight or Adobe Flex). Instead of triggering events on a button click, they should be triggered on the completion of a particular form element or a key stroke. This is not hard to do with today's programming languages. It may require a couple more lines of code to handle the idiosyncrasies, but at the end of the day, the extra work for the developer will pay dividends over the work required by the users.

Please, do a friend a favor and remove the submit button, be Green and Save a Click.

Use the comments below if you think I am wrong, I will be happy to respond.

Use the Power of the Internet to Scale Your Portal (or any web app)

2009-10-20T06:52:00.012-05:00

Did you know that regardless of your infrastructure, you have the largest, most powerful performance enhancing platform in the world at your disposal? This platform is vast, infinitely scalable and most of all, it's free. What is it and how do I sign up? It's the internet itself! Let me give you an example of how to take advantage of this.

My company does a lot of Portal implementations and customization. Portals are great for users because they consolidate content and services from across an enterprise and present the information in a unified, consistent user interface. iGoogle is a great example. Portals are also a pain in the butt for developers, mainly because of the dozens of integration points that often make up a personalized portal page. The top right corner may be pulling weather information, underneath it a customized stock portfolio, under that company announcements, info from your HR profile, personalized lists of your client accounts, etc. Each of these blocks of information (or portlets) make individual calls to retrieve this context-specific information. So one call to your portal page, often turns into dozens of portlet requests to your data center. That load adds up quickly and makes performance and scaling a challenge.

Regardless if you're running a portal or not, the key to good performance (and ultimately scaling) for any web site is caching. A great rule of thumb is, the closer the content is cached to the end user, the faster it 's delivered. If the content is cached in their browser (i.e. an image) bingo, it's there. If you have to go back to the webserver to retrieve a pre-generated HTML page, it's a bit slower. Have to go back to the app server (behind the webserver) to run some logic to create the HTML page, slower. Have to go back to the database to pull some data the app server needs, slower still. Have to go to some external ERP or a content provider, slower, slower, slower.

There are several persistent and in-memory caching options out there that you can use to avoid multiple trips to external systems. But what about avoiding trips to your data center all together? This is where the internet comes in.

Every request (from a user) and response (from a server) sent through the internet hops across several intermediary servers between your data center and the user's web browser. At each of these hops, the intermediaries check what are called "response headers" to see how long they can cache the data that has been made from previous requests. That means when person "A" requests weather for Chicago, if your system is architected right, the next person will get the same information without having to go to your data center to get it.

The key to enabling this caching is two fold. The first is customizing your URI (i.e. URL) to be specific to how you want data to be cached. The second is using the response headers' cache-control directive to determine how long that URL's data should be cached (i.e. one hour, one day, one week, etc.).

For example, if your page's or portlet's URI is "http://www.mycompany.com/weather" and the responsibility is on your webserver to figure out where that user is from and serve up weather appropriately, caching on intermediary servers is not going to do anything but cause problems. But if your URI is "http://www.mycompany.com/weather/Chicago" now you have a specific request that can be cached for up to 12 hours. Any subsequent requests by Chicago-based users isn't going to hit your data center and will be served up by intermediary servers. This decreases load on your servers, increases performance and quickly adds up to huge hardware savings.

The same trick can be applied to any relatively static information. Use response headers to cache information that isn't going to change that often. And if the information is personalized, figure out how to bake that personalization/segmentation into your URL so the context-specific data can still be cached by intermediaries. This may not apply to exclusive information (i.e. account balances) but if you utilize AJAX and REST in your page creation, that can be a small hit to your data center, while the rest of the page is rendered from cached information on intermediary servers.

So use the power of the internet to your advantage to scale effortlessly. If you think about most page's makeup there is a very small part that is truly user-specific. The rest of it can be served up by the internet at large, and that's a great way to scale without spending a dime!

This blog was also picked up by CIO.com

Rubbin's Racin - Infrastructure and Apps Need To Work Together to Win

2009-10-16T21:14:00.003-05:00

Did you ever see that (terribly) awesome movie, "Days of Thunder"? If not, watch it, it's probably on TBS right now, or just read this. . .

From my experience, Infrastructure in IT is about building a car , and Apps is about driving that car. One can't succeed without the other. Success is determined by the fans of the car and the driver. If the car wins, awesome. If the car loses, who's fault is it, the car or the driver? The fans don't care.

I like to build race cars (I am a young Harry Hogge). I admittedly grew up as a Cole Trickle, but now when it comes to building scalable computer systems I think about the infrastructure first: The network, the memory, the CPUs, the storage and the car's internal computer (you know, the middleware, the stuff that makes sure that the driver can 'safely' use all of that metal to it's fullest potential).

So who are the cars' customers? Application developers. They are the drivers. Cars are built based on the developers' requirements. But often the developers are constrained by the car provided to them. They can only turn the corner (or process transactions) as fast as the middleware (computer) will let them. They can only go as long as the gas tack (storage) is available. When they launch the car they find their racing lines in the context of what the car can handle. But whatever path they choose, it's the car's responsibility to ensure the path scales, that it's consistently available for every loop around the track.

The unfortunate reality is that most organizations put a wall up between the car (infrastructure) guys and the drivers. They point fingers at each other when something goes wrong, performs poorly or doesn't scale. You hear things like "Cole Trickle doesn't know how to drive the car the way it was meant to be driven" or "Harry Hogge's car is a piece of garbage". Or in IT terms. . . "Cole's code is waaaay too memory intensive and needs to be optimized" or "Harry's RAM allocation for our application is ridiculously low and needs to be increased."

The reality is. . .the fans don't care. They don't care if you're a mechanic or a driver, if you're on the infrastructure team or the apps team. The only thing the fans care about is if you're winning or losing. And you can't win with a bad car and a good driver or a good car and a bad driver. You need them both. One can't win without the other. And the better they work together, the happier the fans will be.

-J

Good 2 minute video on Why Google Wave

2009-10-03T08:43:00.002-05:00

Thanks to Epipheo Studios, a solid explanation on why Google Wave will rock. . .

Gmail's Down: When Redundancy is Not Enough. What We Can Learn About Fault Tolerance

2009-09-07T00:04:00.031-05:00

Last week, Gmail failed for over 30 minutes. Some really smart people keep that service running for millions of users. What happened?!? Here's the story and the lesson we can take away about fault tolerance, business continuity and disaster recovery.

"...we had slightly underestimated the load which some recent changes placed on the request routers,” Ben Treynor, Google site reliability Czar wrote “At about 12:30 p.m. a few of the request routers became overloaded and in effect told the rest of the system 'stop sending us traffic, we’re too slow!.' This transferred the load onto the remaining request routers, causing a few more of them also to become overloaded, and within minutes nearly all of the request routers were overloaded.”

This is an interesting case study. There was no "single point of failure" here, which is what many enterprise's data centers bank on for business continuity. In fact, there were dozens of request routers at Google. As certain routers became overloaded, fail-over to alternate request routers worked exactly as planned. Redundancy, check. Fail-over, check. What could go wrong? The daisy-chaining failure that occurred is an effect that has a very reasonable cause: Not considering the "Factor of Safety."

I was educated as a materials science engineer. Although my degree has limited applicability to my career, there are a few things I learned that I apply to IT systems design. A big one is a structural engineering discipline called the Factor of Safety (FoS). In layman's terms, the FoS is simple. If you're building a bridge to support 100 cars, you have to construct it to support at least 1000. This is a FoS of 10.

If your car is driving over a bridge with 99 trucks carrying a dozen lead pipes, this FoS seems reasonable. You want to be sure you're going to be OK, and a FoS of 1 or 2 doesn't guarantee that. The engineering discipline states that components whose failure could result in substantial financial loss, serious injury, or death can use a safety factor of four or higher -- most often ten, like our bridge.

So what am I getting at? Google didn't have the appropriate FoS applied to their failover/business continuity strategy. I don't know the factor they used, but my guess goes something like this:

We have 10 routers at 75% capacity. Every time a router starts peaking over 80%, it conservatively considers itself overloaded, and passes its load off on to the next nine servers, which quickly peak over 80%. The daisy chain continues until you can't get your e-mail.

Both the FoS and the load-balancing configuration they had with their active router hardware were wrong. They may have felt they were adequately prepared by "engaging" more hardware than was needed. In reality, they needed a FoS of at least four times the number of routers they had.

Business continuity means asking the question "what then?" after the question "what now?" has been answered. It's preparing for the after-shock of the original effect you initially designed to address.

I understand that, after a point, a certain FoS might become unreasonable, but you can still account for it in either your disaster recovery plan or service level agreement. For example, you can state that you can handle a 400% increase in load in your local data centers after which you will need X amount of downtime to divert traffic to secondary, public cloud-based environments. Of, if (God-forbid) a data center is destroyed, that the backup data center may only be able to handle X applications.

So the take away is this. What's your FoS? On a bridge, 2 doesn't cut it. And unfortunately, we're all on that bridge. When we're dealing with possibilities of substantial financial loss, serious injury, or death, my engineering discipline tells me we've got to think harder than ... "We have a DR center."

We can't just think about "what if?" we have to think about "what then?" The answers aren't much different (process-wise or technically) than what you already have, but having it thought through, will make a safer place.

-J

Jidoka - How to Ensure Your Job is NOT Offshoreable

2009-07-28T00:10:00.007-05:00

Do you ever worry that your job might be "offshoreable" in the future? If not, you should, there's a lot of "smart" people out there that are claiming it's the end-all-be-all cost-saving solution to every business process. If you have worried about it, I have the steps you need to make sure it never happens.

Jidoka is a Japanese word that translates to "Autonomation". It is used in the Toyota Production System (TPS) and Lean manufacturing techniques. It has been described as "intelligent automation" or "automation with a human touch." The concept of Jidoka is simple: Humans are flexible, they are good at adapting and making changes, but they are not very good at completing repetitive tasks. Machines (or computers) however, are not very flexible, but they do a very good job at completing repetitive tasks. Autonomation is about developing processes and systems that understand these key points and leverage human and machine resources accordingly.

This may trigger a "No duh." response. But one aspect of Lean manufacturing that we often do not implore, is the concept of Kaizen, or continuous improvement. That is, continually looking for opportunities to remove humans from completing repetitive tasks, and put them in positions of management and oversight where they can implement continuous improvement of the processes they are involved with.

Think about your life for a moment. How much of your day is spent completing repetitive tasks (on and off the job)? Whether it's plugging data into a spreadsheet for budget tracking, responding to the same type of email question/request over and over, or heck, even going to various websites to get your local, sports and social media news. How much time during your day do you spend doing the same thing, over and over?

On the personal level, there's a great book by Tim Ferris, "The 4 Hour Work Week", that offers some suggestions on how to Autonomate various aspects of your personal life. Some of them are far-fetched, but the concept is sound. Stop Wasting Time.

The same discipline can be applied to ALL of our jobs. We all have processes in place we're required to participate in as a part of doing our jobs. But how can we make those processes better? How can we remove ourselves and our colleagues from doing repetitive tasks and Autonomate them? Note, the word is not "Automate". We're not talking about replacing humans here, we're talking about increasing their efficiency and allowing them to focus on oversight and things that matter (continuous improvement), and not on the repetitive tasks.

Some people's answer to process improvement is by offshoring the task. Send it overseas to cheaper labor, and let them complete the repetitive tasks. This may seem to offer some cost savings in the short-term, but this often introduces other issues and inefficiencies, while still not addressing the core issue that humans (no matter where they live) are not very good at completing repetitive tasks. This is one of the major reasons there is so much attrition in offshore firms. Offshore employees are not going after more money somewhere else, the truth is, they get bored! Ultimately, the attrition you see requires more people that need to be trained, more offshore management and oversight needed to oversee new recruits, and the more the cost "savings" shrinks to the point that it negates the competitive advantage that was being explored. This result has been seen in offshoring everything from financial management, to call centers, to software development.

If you want to ensure your job doesn't get offshored, then you need to figure out ways to Autonomate your job. Figure out what aspects can be given to a machine. Let your stakeholders know that the more they can automate, the more responsibility you can take on, the more efficient you can be. You can get out of the role of being an "operator" and into the role of a true "knowledge worker", a differentiator, a competitive advantage.

Before you ever ask yourself the question, "Is my job offshoreable?", ask yourself the question, "Can the processes I'm a part of be Autonomated (Jidoka)?". I guarantee that if you're continuously doing the latter (Kaizen), the former will never be a question.

-J

What Facebook Is All About

2009-07-27T20:50:00.004-05:00

OK, this isn't really in-line with the Technology Edge theme, but if you're a FB user, it is funny. . .

A Message for the Millenials: How to be Successful in Business

2009-07-18T01:46:00.015-05:00

I have a few younger siblings that have recently entered the workforce. This blog is for them and their friends. It has nothing to do with technology. It contains a few very simple, tactical "habits" that I feel everyone needs to follow to be successful in business.

1) Never Answer Your Cell Phone in the Middle of a Conversation (if you answer it in a meeting, you could/should be shot).
This seems obvious but you'd be surprised by how many tenured people break this rule. This was taught to me by an old mentor of mine, Gautam Shah. He said, "Answering your cell phone in the middle of a conversation, even a water cooler conversation, is disrespectful and negates any goodness that could come from that conversation. At that moment in time, the person on the other end of the line is no where near as important as the person you are talking to." 15 years ago, before cell phones, this wasn't an issue, and it shouldn't be today. You should always be engaged with the person you are speaking with, it establishes report, respect and trust. And, God forbid, if you're in a meeting, and you answer your cell phone, you should be wrapped up in the projector screen and bludgeoned with whiteboard dry erasers, because you just made an ass of yourself.

2) Always Bring Something to Write With
My first day of work at Andersen Consulting, I was told by a very smart guy, "Whenever you get up from your desk, make sure you're carrying a piece of paper with you." I smiled and asked, "OK, why?" He said, "It doesn't matter if you're going to a meeting, walking across the room or going to the bathroom, if there is a piece of paper in your hand, you're busy, if you have nothing, you're wandering." I think this is an important lesson for anyone in business. Perception is reality. It's especially important if you're called into your client/bosses office. ALWAYS, bring something to write with. ALWAYS. Never go into a meeting (any meeting) empty handed. Being empty-handed totes an essence of disrespect and uncaring. Oh, and don't forget to WRITE STUFF DOWN. Taking brief notes, even trivial ones, demonstrates that you are engaged and that you care about the conversation.

3) Don't Cross Your Arms When Someone Is Talking to You
This is a funny one that I was guilty of for a number of years until I took an Improvisational Acting class a few years ago (which I recommend to anyone in business). The teacher of the class, Steve Roath, would always point people out who were crossing their arms, before making them put them down. He said, "Crossing your arms creates a barrier between your mind and the knowledge or opinions being shared by others." As subconscious as this reflex may be, I believe he's absolutely right. I've made it a point to acknowledge my arms in conversations and in meetings and I find that when I do cross them, subconsciously, it's typically (for me) a defense mechanism. By lowering them I instinctively open my mind to listen to the information being conveyed to me, and I'm much more apt to listen more fully and to either learn from that information, or craft a much more intelligent response. In summary, don't ever cross your arms. It's a terrible defense mechanism. If necessary, put your dukes up!

4) Make a Real Difference by Creating a Job for Someone Else
This was the most impactful lesson I learned, and it came from Robert Blackwell. Robert and I were at lunch a number of years ago, talking about my then-career as an independent consultant. He asked, "J, do you think doctors are successful?" I replied, "Yes, I think doctors are very successful." He responded, "I think doctors do great things, but it's the guys that build hospitals that are successful, because they create jobs for doctors." That statement always stuck with me. It should be our goal to not just fill a role for ourselves, but to create roles and jobs for others. You don't have to be an entrepreneur or a financier to do this, you just have to figure out ways to save your company money or increase it's revenue. So whether your helping a business operate or helping a business develop and grow, you have the opportunity to make a difference, and ultimately, if you do a kick ass job, you will create a job for someone else. That's what makes America great, and how you can be a contributor to it's continued success.

These are a few tips, there are a gabillion others, and that's what blog comments are for. So tell the Millenials, what are your "habits" that you'd like to share with our future leaders?

-J

What is a Solstice Consultant?

2009-07-15T07:27:00.002-05:00

One of the places Solstice derives great talent is through it's highly acclaimed, paid internship program, focused on giving college students the opportunity to build experience delivering projects across IT, business process optimization and marketing/change management. Each intern is required to complete projects across all of these domains, in the Solstice spirit of building cross-functional teams. The YouTube video below is a recruiting video a few of our interns have put together about what it means to be a Solstice Consultant.

How to Consolidate Twitter Feeds using Yahoo Pipes

2009-07-14T10:30:00.012-05:00

Guest Writer: Kelly O'Regan - Solstice 2009 Summer Intern

We recently launched a Twitter account for Solstice. Our goal was to consolidate the twitter feeds from all of the thought leaders in our organization into a single feed for SolsticeLLC. We wanted to accomplish this utilizing purely SaaS and Cloud-Based Platforms. I was able to accomplish this in about 4 hours (including research). Here's how I did it:

In order to complete this process, you’ll need to have 2 accounts, a Yahoo! account and a Twitterfeed account

Start by logging into Yahoo! Pipes with your Yahoo! email address:

1. Click on the “Create a Pipe” link in the top toolbar.
2. To begin, we need to define the content to pull through the pipe. In our case, it will be the RSS feeds from several Twitter accounts.
3. To do this, under the “Sources” dropdown menu in the left hand toolbar, drag a “Fetch Feed” source into your workspace.
4. Here, you can add numerous Twitter RSS Feed URLs to the pipe. To find that URL, go to the Twitter page for whom you’d like to use, and click the “RSS” button in the address bar.
5. Copy the web address once the RSS feed shows up.
6. Paste as many RSS feeds into the Fetch Feed URL boxes. To add more boxes, simply click on the “+” next to the URL.
7. Connect the Fetch Feed module to the Pipe Output (See NOTE below for additions to this Pipe).
8. Click “Save” in the top toolbar.
9. Once you’ve saved your new pipe, click on the “Back to My Pipes.”
10. Click on your newly saved pipe. As you and your colleagues start tweeting, the content will show up under the “List” section of this page. To get this, click on the “Get as RSS.”
11. Copy the link in the address bar, and open a new window.

Next, log into twitterfeed.com:

1. On the Dashboard, click “Create New Feed.”
2. Twitterfeed connect to your Twitter Account- Make sure the one it’s logging into is the one you want other accounts to streamline into.
3. your Feed (Does not show up in any way on your Twitter Account)
4. in the Yahoo! pipes RSS feed.
5. Click the Advanced Settings link, and choose the update frequency and any other additions you’d like to make.
6. IMPORTANT: Be sure to uncheck the “Post Link” box so that your urls aren’t repeated.
7. Click “Create Feed.”

NOTE: Connecting this module to the Pipe Output is the basic form of funneling your tweets into one account. However, there are a few additions to the pipe that might make your Twitter page look a little more polished.

For example, the feeds come through prefaced with the username of the person who originally submitted the tweet. To delete the username associated with each Tweet:

1. Under the “Operators” drop down menu, there is a module called “Regex.” Move that module onto your workspace. The idea of this module is to take out the name of the user who makes the post (ie. “johndoe:” will be removed.)
2. The pattern should read like this: In “item.title” replace “username:” with “______________.” (Do not insert any content.)
3. One of these lines should be added for every Twitter account linked to this Pipe.
4. Connect the Fetch Feed to the Regex, and then the Regex to the Pipe Output.

To Filter out Retweets from being Retweeted:

1. Under the same dropdown menu, “Operators” drag a “Filter” module over to onto your workspace. Here, we will be blocking out anything in the Tweet that would be retweeting an already retweeted piece of information.
2. Within the Filter module, the block should read like the following:
3. “Block” items that match “any” of the following:
4. “item.title” “contains” “RT.*RT”
5. Connect the Fetch Feed module, to the Filter, and finally to the Pipe Output.

That's about it! If you have any additional suggestions or questions, please post them in the comments below. Happy Tweeting!

-Kelly O'Regan

Nice Layperson Overview of Cloud Computing by SF.com

2009-06-09T14:13:00.001-05:00

How to Network Effectively

2009-05-29T13:15:00.006-05:00

A couple years ago I attended a seminar on effective networking given by Lillian Bjorseth of DuoForce Enterprises. It was a great talk and I took the following notes. I stumbled across them recently and they were great rules to refocus my networking efforts. The notes are broken out as rules to follow before, during and after the event.
________________________________________________________

Networking is more about giving than getting. Sales is harvesting, networking is planting seeds. Do not go to networking events to sell, go to plant seeds

Before The Event

CREATE A PLAN OF ATTACK

I. WHO YOU ARE

Know what you do
Know what you do differently
How to be memorable
They will not refer you if they do not understand what you do
How to people benefit from what you do?

II. TARGET MARKET

Where is your target market what are their organizations and events?
Get ROI out of your organizations, don't join everything, time is money
Go to places where people can introduce you to your target market

III. IMPRESSION MANAGEMENT

Dress

Brown is not a power color
Navy blue – authority, trust, knowledgeable
Black – powerful (sometimes too powerful)
Sky blue – tranquilizing
Jacket makes you 1/3 more powerful

Posture – confidence

When talking with someone standing boxed off (belly to belly) prohibits others from joining. Open stance (angled) is more welcoming, depending on the situation you may want to do both
Stand up out of respect when someone approaches you to say hello/introduce themselves,
Don’t stand over people that are sitting, sit down with them
Handshake – hand on top – controlling, hand on bottom – submissive, sandwich too personal, limp fingers = wussbag. Go web to web, keep hand firm.
Name tag – always where on right side so people can see your name when they shake your hand

IV. VERBAL BUSINESS CARD (front end of your elevator pitch)

1 or 2 sentence laden with benefits, memorable, contains your name, what you do, active verbs (help, share, work with).
Do not include company name, geographic location, adjectives, adverbs or the HOW.
You want the verbal business card to elicit the question of “How”.

During The Event

10 minute rule to work a room (you can determine if you want a relationship with someone in no longer than 10 minutes) Ask “Why” questions “ Why did you join this organization, why did you choose this event, .
Always ask for a business card before giving them yours (polite)
Look at the business card when they give it to you.
Ask four questions to determine if they are worth a relationship (have these prepared in advance). Listen for the answers!!! Prepare your ask-for questions in advance to focus your interactions. Listens for the answers because you know best what you want to hear back.
Try to find commonality (sometimes business card will give you this)
How to end the conversation: Don’t look around for others.
If you want a follow up: “I really enjoyed talking, can I email you that report I was telling you about”
If you don’t want a follow up: “I invited a guest and I want to see if they’ve arrived”

After The Event

Do what you say (i.e. send them what you promised),
Set the standard for the relationship!

Saas and Open Source alternatives to Commercial Solutions

2009-05-26T08:20:00.000-05:00

Solstice and our clients have had success with the following alternatives to Commercial Off the Shelf Solutions. Let me know if you need any guidance on how to transition to these lower cost solutions.

Category	Proprietary Market Leader	OSS	SaaS
Office Productivity	MS Office	OpenOffice	Google Docs
Customer Relationship Management	Siebel	SugarCRM	37Signals HighRise
Human Resources Management	PeopleSoft CRM	OrangeHRM	Zoho People
Content Management	Interwoven Teamsite	Drupal, Joomla	TBD. . .
Portal	IBM Websphere Portal, MS Sharepoint,	Liferay, .NETNuke	Google Apps
Collaboration	MS Exchange, Lotus Notes Domino	Zimbra	Google Apps
Social Networking	TBD (MS, IBM, Oracle)	Elgg	Ning.com (free), KickApps (sub),

Pros and Cons of Open Source vs. SaaS vs. Commercial Software

2009-05-21T08:10:00.009-05:00

The following table outlines some pros and cons of open source vs. Saas and COTS solutions. Leave a comment on anything I might be leaving out or not considering.

	Commercial Off the Shelf Products	OSS Products	SaaS Products
Speed to market	New features are packaged and released based on corporate release schedules	Feature Driven Development – new features are often made available as soon as they are built and certified	Immediate. No initial installation. Features are often slipstreamed in as they are developed
Customization	Typically limited and due to proprietary nature of systems, makes upgrades difficult.	Best option for customization with products embracing open standards. OSS was founded on customization.	Worst option for customization, although depending on the platform, may offer some options.
Interoperability	May or may not embrace open standards	Typically based on open standards, easier to share info between systems	It depends, but most successful SaaS projects are open enough to allow for plugin development (i.e. GreaseMonkey)
Support	Depends on vendor and support plan	Community driven, the more active the community, the better the support. Many established OSS projects also have paid support options	Typically the best, since if one person is having the problem, everyone is having the problem.
Vendor Lock In	Vendors are financially encouraged to promote platform lock in	Flexibility eliminates lock in	SaaS vendors are also financially encouraged to promote platform lock in, although exports are more standard.
Security	Vulnerabilities typically take longer to assess, fix and deploy.	Studies show OSS tends to be more secure than proprietary. Patches often delivered in hours vs. days or months	Security tends to be the best for viable services providers.
Total Cost of Ownership	TCO often involves software licensing, upgrade, support and larger hardware costs	Studies show 90% lower TCO for open source solutions	For SMM’s, TCO tends to be lowest for SaaS since you only pay for what you use (i.e. per user licensing) with no support or hardware required.
Staff Retention	Skillsets are often constrained by the products you have purchased	Open source attracts innovative people and builds “street cred”. They feel part of something bigger.	End users love it, developers/administrators dislike due to black-box/outsourcing nature

Private vs. Public Cloud

2009-05-13T20:50:00.002-05:00

Google came out with a blog post recently touting their public cloud vision. VMware responded with a blog touting why the private cloud concept was better. Who's right? Both of them. VMWare's private cloud vision will help companies maximize their existing infrastructure investment, while Google (and Amazon) is focused on building a platform for the future. The comment I left on the VMWare blog is an attempt to marry these two visions into a near term and long term strategy. Here's what I wrote:

This is a great post and brings some sanity back to Google's claims, but there are some points missing:

First I have to agree, for companies that have already made a capital investment in infrastructure, using VMWare to create a private, internal cloud is the way to go to maximize flexibility, elasticity and utilization. But there is one thing the public cloud providers have that ultimately will win the race, multi-tenancy. The public cloud providers have the ability to house multiple companies/accounts on the same hardware to maximize utilization. This ultimately will lend to higher utilization and a lower cost/CPU cycle. It's very difficult for a company to achieve the same levels of utilization/efficiency independently, particularly if IT is not their core business.

There are privacy and security issues that accompany multi-tenancy but ultimately they will be worked out. There are bright minds working on them and at the end of the day, it just makes sense. This is why power plants exist and every building/house doesn't run it's own generator anymore.

On the point of flexibility, Google is a bit behind but Amazon's EC2 supports a myriad of platforms, including Windows, Solaris and Linux. To remain competitive, Google will need to as well.

In the near term, private and hybrid clouds will take hold. But on the 5-10 year horizon, it's seems that the promise of the public cloud's economies of scale will ultimately triumph (for all but the most private applications).

Whether you choose to invest in a private, public or hybrid cloud infrastructure depends on your company's infrastructure capital investment to date, SLA and privacy needs.

1) My suggestion for large enterprises with an internally hosted data center, is to build your private cloud, but look for opportunities to start porting non-mission critical VMs (i.e. test environments, departmental apps) to the public cloud. Over time, as the public cloud matures, more and more of your private cloud's assets can be moved, so you can stop investing capital dollars in soon-to-be-outdated hardware.

2) For those who are outsourcing their data center to a 3rd party, you have incredible leverage to challenge their current pricing models, and if they don't play ball, you have motivation to start moving items to the public cloud more quickly.

3) For SMBs, startups and companies experiencing rapid growth, the public cloud is where you should focus your investment/move your assets. Get on the platform of the future now, so you don't have to pay to move to it later.

If you have any questions on how to do any of these things, drop me an email and lets talk.

-J

How To Evaluate Open Source Solutions

2009-05-05T13:05:00.010-05:00

I've been evangelizing a lot about Open Source software recently. But is all open source software good? No!

The pros of OSS are plentiful, but the cons are just as numerous. With often a myriad of competing OSS projects, many not professionally supported, little certainty around future releases, rapid updates requiring constant upkeep and buggy early versions, how can one justifiably take the risk? How do we mitigate these cons and filter the wheat from the chaff?

The following assessment criteria should start the evaluation of any open source product/platform:

Investigate the licensing/legal situation of the software.
Evaluate whether the software is standards compliant.
Contact references to confirm product viability.
Find products with a supporting or stable developer.
Find products that use an open/industry standard implementation language.
Reference third-party reviews of the software.
Reference books published about the software (the more the better)
Reference industry analysts, such as Gartner, Forrester or IDC.

In general, a mature open source platform will meet the following criteria:

Project extensions are available.
The project has reached a 1 year maturity mark.
Security patches, bug fixes, and new features/enhancements are delivered separately.
The core development team has rigid criteria for participation.
The software has reasonable automated unit and functional tests with code coverage in the 30-80% range.
The software easily integrates with external services
The component’s bug database is kept up-to-date with revision numbers for each product enhancement.
The solution has been ported across multiple platforms (Linux, Windows, Solaris, and Mac).
The community is organized into groups, each responsible for separate tasks (the maintainer, the documentation group, the development group, the evangelism group).
The project’s license is acknowledged by the Open Source Initiative (http://opensource.org).
Large-scale adoption, including both public and well-known large-scale organizational deployments
Separation of documentation: User documentation, Installation documentation, Admin documentation, and Development documentation

And remember to always weigh target usage of the application (mission-critical, departmental or beta) against the OSS product's readiness.

Many of these points were reiterated by our recent discovery of http://www.openbrr.org. Now that's an example of an open source project that lost it's legs, but what was was left behind was some great info. Thanks to that community!

Please let me know some other criteria we should be considering in the comments below. I'll consolidate feedback and send it on to openbrr.org.

-J