The web’s four hats & an overview of HTML5

I recently returned from speaking at a conference in Kentucky where I ended up putting on four hats and seeing HTML5 and the future of mobile computing differently each time. I was struggling with trying to figure out why standards committees take so long to come to an agreement. After all, the vision of the web is clear, right?

Why did we get off the XHTML superhighway and jump on the scenic route where we ignore the bumps and potholes of bad syntax and limited metadata? What kind of folks are driving the bus right now and are they really going the right direction? Should we stay on the bus while we head into Mobileville? I've decided that the questions you pose are at least if not more important than the answers you think are right. Because that tells you what your vision is and if you've followed a little of this blog, you know that strategic vision is important.

The four hats are:

• The Engineer - who likes all of the functionality logically thought out
• The DBA - who likes the the data well defined and stored
• The Designer - who likes to deliver an emotional message to the customer
• The Businessman - who makes sure the customer is happy and they make a profit

Those four hats have led me to not watch the standards groups as much as watch Google and Amazon for what to use in the future that people want. The real vision of the web is to make money by giving computer users what they want. Waiting for standards groups won't get you there. After all, the current prediction is that CSS3 will be completely standardized by 2022.  Here's a rundown on the thinking under each hat:

Engineer

As a software engineer and instructor of many students who become programmers, I know that the web has become populated with these folks that want to turn it into an application environment. That way they can program for it and make it do their will. The back end servers are full of Java, C#, and php and that same force is heading to the browser with JavaScript.

I see the HTML world being altered so that these variable manipulators can have better code and read each other's functions easier. The push in HTML5 towards meaningful naming of the loosely typed datatypes that were divs and spans is going to give programmers a better handle on what it is they are talking to. The code will become less dependent on ids and more dependent on setting up the HTML with the proper element names like <mark>, <time>, <progress>, <meter>, <details> and some of the more argued over names like <style scoped>.

I can see where the types of activities previously handled by JavaScript are being pushed into HTML. This reduces the language down to one, slightly more complex, language. Do we want a merger here of interests? Is the MVC principle being corrupted and should we really mix our text markup with programatic data validation in the same code module? The data and its validation are View Model pieces that are tightly coupled and should be handled together in my mind.

So the future lies with the ultimate merger of HTML and JavaScript and we'll have a Razor style view engine in all browsers eventually. My opinion is not to follow the same syntax and find a better way to merge the two. But the merger will eventually come. Simplified syntax for CSS3 and JavaScript have started to reinvent these stuffy languages and if jQuery can simplify CSS with a replacement like EZ-CSS, sass, or less, then we're on our way. I'm hoping it's not like node.js and stylus, but I need to try those more.

DBA

I also love to understand data and its meaningful use. Having the right field name and the right multiplicity gives me a warm glow. But I also know that too much data analysis can torture those poor programming souls who have to recombine the data for the page they work on.

Here we're not talking about the fields where programmers hand over their data after the output is available but where the data can be semantically meaningful as text. These are the domain entities and at a high level they are represented by <header>, <nav>, <footer>, <section>, <aside> and <article>.

My biggest hurdle here is knowing that the data already comes from a semantically proper framework called the database. If all the work has been done there, then who benefits by rethinking the meaningful structure one more time for the web? The only answer is that the DBA traditionally send the data to the programmers who use that "data markup" for their benefit. The field names become bundled together and as I put back on my Engineer hat, I am happy to create complex View Model types for my View, the web page.

But it's reinventing the wheel when there's a database and it's better for team coding experiences to have more readable code. But wait, is there a web service that might be looking for my article elements? Not yet in the HTML5 way. If you are looking for a current semantic framework of entities, you have to look no further than Google's recommendations. The microformats they recommend carry much more weight for reasons to mark up with them than just a standards board. People are using the schemas for reviews, events, organizations, places, restaurants, recipes, etc. without even knowing about it but you are losing out on having Google process your data and provide search results with it if you don't.

The XHTML push that we unceremoniously dumped was a DBA's dream for a perfect interface language between data source and data consumer. The problem was that it's not a homogenous set of data. Our web DBA's don't work under the same domain and the complexity made it uncomfortable to work with so many needs and choices that we found had already been solved with another data model. Or two (relational and objects). We didn't need a third (XML).

Designer

The designer in me wants to have my great user interface so well integrated into the data and processes that you don't notice. And I want it to be beautiful. That hat wasn't the one the standards committees were wearing when they proposed the gradients and transforms. Misguided blink spans and easy marquees have been put to death as many times as Freddie and Jason but keep coming back for more. Now we have them again, only this time a little more well dressed. I really don't even like the drop shadows but some of these will look much better to the high-res tablet crowd.

I am happy with SVG support and the graphics we can do, but where is my visual SVG graphics designer integrated with HTML and CSS? Android was the last to jump on the SVG graphics bus and most of the rest of the cheesy effects have partial support so I know I will be trying out Inkscape and SVG Edit when I need.  Or I'll just sit back and let the widgets take over for me like the SVG based Chart control in Visual Studio and jQuery plugins.

I find the most pleasure with web fonts, especially Google's public accessible fonts and having Web Squirrel give me everything I need to do it on my server. I can talk to the device to get info I need to deliver a pleasing layout with the @media queries. And when I need that old-timey newspaper look, there's multi-columns, but I fear it's a retro feature that will be better left alone due to the complexity it creates for the layout.

Surprisingly, I think the designer ended up with some of the best improvements. Colors are better defined both with more names and flexible opacity. The video and audio elements will have to wait for the patents to become less profitable while we find a common standard to work with. The dominance of the iPad will force me to encode a different way but I don't like it.

Businessman

If you want to know who is going to win the HTML5 battle, you just have to follow the money. And the hat in charge of the money is the businessman. This hat is the hardest to wear since it requires you to not think technically and focus on the customer. Does the customer really want what we think is geeky cool warez? Probably not.

I liked the idea of doing a survey of the currently used names for divs and classes in the wild in order to understand how people used HTML. But what were we supposed to do with that? Did I really want a better element because I was really happy with just calling my div a wrapper in the id and not a section. You want me to recode it? When?

What helps me make money? Coding faster. Reusing other people's code. If all you do is rename things, then it's going to get in my way. Now if you make it easier to find elements in CSS by adding better selectors, I'm not going to complain but it is looking more and more like a grep or regex language these days.

I can reuse other people's code if they've marked up what I want to use and now we're back to microformats because what I want is not generic text groupings that are or aren't related. What I want are finer granulation on the most common business entities which is exactly what the microformats do.

Other types of useful abstraction that will be faster or give me critical information are the new communcations APIs like Web Workers or Web Sockets and the ability to let me work offline with session or local storage when paired with the page caching. Geolocation is just a one-trick pony but had to happen when you start moving yourself around instead of sitting at the same IP day after day. And the database storage on the client will improve the user experience for offline as well.

Conclusion

People want a desktop application experience on the web and want it whenever they want it there. People have to have it easy and that means the developers as well as the users. So will I use the semantic markup? Probably. It will help me as a programmer. Will I use the <canvas> and other graphic elements? Probably not. I like SVG and JavaScript generated graphics as long as I don't have to write it. I can use Adobe Edge or other visual programs for that. Will I use the features that aren't well supported like drag & drop and datepickers where I can use jQuery and jQuery mobile to get standardization now? Obviously not.

The 2-D and 3-D graphics are incredible and not in my realm as a web developer but if you are a game developer that wants to leverage the e-commerce platforms of the future like the Apple App Store, Android Marketplace or possibly the Amazon juggernaut commerce system, then you must develop using <canvas> because it's the fastest and standardized.

As to why standards groups like the W3C and WHATWG don't move too fast, it's because you have four different groups of people all lobbying for their view. The DBA had the upper hand in the last version and now the designer and the engineer seem to be dominating. But like a real business, it's the dialog that is important to crafting a best solution for the whole. Let one company or one hat take over and it would be an impending fail.

The businessman is going to take you to that application experience that you so want. And he will charge you for it and pay you to develop great apps for it. The standards committees don't think like businessmen so you'll need to see what people are really using, really need, and get paid for. My best bet is to watch Google for how they use search data and to watch Amazon for how they will use their e-commerce platform. Of course, you'll also be watching Apple and Facebook as app delivery leaders. Then code for it and enjoy.

KCMO is added to Google fiber network project!

google A Googler 

 by KC_next

Crossing the river from Kansas City, KS to Kansas City, MO: ultra high-speed broadband available in both KCs in 2012http://goo.gl/hCyYR

5 hours ago 

KC_next KCnext 

Google will extend ultra-fast Internet project to Kansas City, Mo.bizjournals.com/kansascity/new… via @KCBizjournal

6 hours ago 

KC_next KCnext 

The official video on today's exciting news that Google Fiber is expanding into Kansas City, Missorui http://youtu.be/TmSuNyOpsXU

6 hours ago Favorite Retweet Reply

Kansas City gets a gigabit heart from Google. The Wizard is back.

Image via Wikipedia

Yesterday, Google announced that Kansas City, Kansas was the winner of the high speed fiber network deployment that took a year to decide. It's as if the Wizard of Oz came to town and got a job as CIO with the KCK government. Certainly Topeka was a noisy contender getting Google's attention last April 1st with a Google Doodle to suit the occasion. But it was the solid community behind Mayor Joe Reardon and the business support groups that swayed Google to bring gigabit speed to our prairie town.

Some of the groups that have participated in the decision, I'm sure have been the Marion Ewing Kauffman Foundation, KCNext, and the KU Med Center. The Kauffman Foundation in particular has been the leading supporter nationally for the education of entrepreneurs and now gets to take their passion for community building into the grey streets of KCK.

Google is also interested in supporting the Kansas City, KS community through non-profit groups. It's important to raise your awareness if you are helping to benefit our area through technology to get on their list by registering with them on their site.

The first thing that KCK will benefit from will be the build out of the network where local folks will get jobs  necessary for running cable and building infrastructure. It will take some time before the users of the network get to benefit from any kind of high speed surfing. But it won't be the browser and texting users that will see an increase in speed as much as we'll see other benefits. Sure we can knock on the doors faster asking for web pages but most of the world can't respond at the same speed so most of the responses will be just as fast.

There are large consumers and producers of internet information here around Kansas City and for the people that access that information, they will be seeing a better response time. Maybe the people like Infegy, a social monitoring service, or AdKnowledge, the largest privately owned advertising network, will move some of their operations over to KCK to take advantage of the speed and produce better and advanced services.

One thing I have to answer for myself is just how the fastest fiber network that is currently available in the area will play into Google's plans. The Sprint backbone of fiber supports telephone communication and for personal use, hardly anyone gets to benefit except for those that pay to use it to support their phone systems. The military certainly is a major consumer of the fiber backbone with Ft. Leavenworth being a quiet powerhouse on the digital frontier. Sprint has been longing for a partner which they might just have found in Google. They were ignored as a suitor once more for the merger of T-Mobile recently. This could have big implications for the future of Sprint.

I'm certainly excited about all the future possibilities that Google has honored our area with. We're a great community that was waiting for that perfect storm which I think is finally here. The parts we needed were the technological know-how that Sprint attracted in the last decade, the entrepreneurial impetus that the Kauffman Foundation is continuing to supply, and now finally the infrastructure from Google that will generate decades more business energy to a community that deserves the best.

Related articles

• Google Starts Experimental Fiber Network Rollout With Kansas City (circleid.com)
• Google bestows 1Gbps fiber network on Kansas City, Kansas (arstechnica.com)
• And the Winner of Google's Ultra High-Speed Internet Is ... (mashable.com)
• Kansas City first to get Google's 1Gbps Internet (geek.com)
• Google's 1 Gbps Fiber Service Coming To Kansas City & Community, Nowhere Else (blogherald.com)
• Google gives Kansas City Gigabit Internet (tech.fortune.cnn.com)
• Kansas City, Kan., to be Google's broadband test bed (news.cnet.com)

Test first – don’t hire an analyst? Project management reorged.

Coders are being asked to write tests before coding. Testing first sounds cutting edge. But let's get real. You don't have anything to test so it's not testing. It has to be something else.

I’m not objecting to the practice, just the naming. That’s because I’m thinking like an analyst instead of a programmer. Naming determines the direction of the thoughts from that point on. We shouldn’t tell people to test something they don’t have because it’s not right.

Ask any Denver bound passenger on a plane to navigate where they are going. The chances of getting to Denver are about as good as having a project complete successfully without analysis. The analysis is your plan, your map, and your radar. The destination is your business goal.

Testing in project workflow
There are several concurrent workflows during a project. Each basic workflow takes up a majority of the current activity during the project at some point can occur concurrently with most other workflows. Here’s my version of the project workflow without any particular allegiance to another methodology. It’s what I’ve found to be a cohesive set of activities that require unique skill sets.

• strategy - coming up with a good business idea
• project initiation – committing assets to making the idea real 
• needs – talking to folks about what they want based on that idea 
• requirements – understanding and communicating those needs in testable terms 
• analysis - organizing business data and workflows based on those requirements 
• design - figuring out how it's all going to work with what we have for the technical folks 
• implementation - the construction 
• testing - the double check of validation and verification 
• deployment - getting it launched 
• maintenance - keeping it working and updating it 

What do you do when you test?
Testing is about two things. It's about validation and verification. Validation is checking stuff that has been planned and making sure that the plan was carried out. Verification is about seeing happy faces on your stakeholders no matter what they said and what you wrote down in your plan. Valid product + verified happiness = project success.

Testing can start as early as the requirements phase. Since the project is being expressed as testable statements, it follows that testing can start early. The information that is extracted at that point is useful for planning and setup. Then more planning is done throughout analysis and design for the large scale types of tests that match up with the large granular data definitions and workflows.

When the granularity of design comes down to chunks of code and individual statements, you still have testing that goes on. It is this drill down into the finer details of design that the test first advocates are talking about. Here the design is put forth as a supposition and as it gets implemented it is pushed back into the validity loop of testing. Hopefully, there’s enough high-level analysis and design to make this low level design and testing stress free for the coder.

Test-Driven Development in isolation
Testing is not what is done before you write code. It doesn't matter how much you like Kent Beck. Kent says that Test Driven Development (TDD) is a style of development. So, it's not a style of testing? What's the first step? It's assert. What do you assert? Now you have to go to your data and workflow models to figure that out. What? No analysis and design models?  But if you did have some analysis, then you could do technical design and get the rough sketch of the code.

The TDD coder is supposed to come up with types of tests to run (analysis level testing), rename identifiers (analysis), assert first (analysis), test data (design level testing), and practice this iteratively. If the analysis and design work had been done previously, the coder could use it.

And if you don’t have any of that, you do the best you can and try to figure it out. Some programmers use pseudocode and activity models called flowcharts for their technical design. They were trained to take exercises in programming class and wrangle them into code without any supporting analysis or design. Management got trained into thinking that the real world was the same and programmers could pseudocode the entire business project given enough bright students.

So, as an analyst, I was interested to figure out what programmers were being told to do if they only had a listing of needs from the stakeholders.  That list is usually so hard to understand that without proper editing and rewriting, the resulting code is flying without radar. Testing first in that case could be about several things including

• testing stuff that you make up on the fly
• doing something else and calling it testing

Most of the principles used in TDD are based on doing what hasn't been done before which leads to higher stress in the programmer because they have a greater responsibility. With the TDD process in a less than perfect design world, the programmer has a way to manage this chaotic development cycle from their chair. Management is more satisfied when the coder does the analysis and design on the computer because a business analyst position would cost money. Productive work on computer is good, work on paper – not so good.

Make it work first, then make it better.
The mantra of TDD is red/green/refactor. When I personally use it in practice it turns out to be, guess/make it work/make it better. I was told to do that by senior programmers.  I've been doing that as a programmer for too many years as a way to manage when the analysis wasn't done. Guess what the stakeholders want and try to get it into words that you can manage. Then turn that best guess into workable code that won't break. And if you have any time after that, give it some thought on how to reduce the code or make it more reusable.

I know that Beck is more interested in getting the gap controlled between decision (design) and feedback (test) so any thinking is good when it shortcuts the path to better code. But analysis isn't good at giving feedback so to a programmer, it's better to have some concrete metric of success rather than a bunch of papers. Write another automated test. One more green light.

Maybe that's partially the fault of revamping our programming curriculum in school and leaving out structured programming. The dearth of analysis after object oriented programming took over had the programmers clamoring for some sort of control that worked.

What's the most important quality of a requirement? It's testability. So if you gather some related needs and can conceive of a test for them, then it usually becomes a good requirement. The remaining tests are easy to extrude from the requirement.

I think coders flipped this on its head. They say that they should be able to conceive of a test and see if it fits the requirement. From their perspective, it makes sense because they have to see the linkage back into the stakeholders' requirements from where they sit in their 8x8' cube. Without guidance they have to draw the map.

But coders aren't looking at the big picture so I'm against TDD being a stand-in for analysis. It works for low-level design though. And it makes sense. So as long as the analysis is sufficient, TDD works well as a design phase validation of the requirements in analysis to the working code put to the fire by automated tests. If activity is anything before the unit tests, the lowest level test possible, then it's not about the test, it's about the requirements.

Related articles

• The History of JUnit and the Future of Testing with Kent Beck (se-radio.net)
• Test driven development at Transloadit " Debuggable Ltd (debuggable.com)
• Be professional, do TDD (weblog.madebymonsieur.com)
• TDD for product dev: Where we're going we don't need... roads (scrollinondubs.com)
• Making Software: TDD doesn't work; Architecting is mixed; scripting is great (computinged.wordpress.com)

Share your business assets for the future. Business models and social architectures.

While designing a social web site and being annoyed by all the bickering social media (share me!, no share me!), I was distracted and came up with a new way to understand business assets. Some people would call it Web 2.0 or social marketing but to me it's an evolution of web site or enterprise level architecture assets no matter what buzzword you like. The public (the internet) and the enterprise are thinking along the same lines. Business has always used the same types of assets, but without computers, we didn't have much change unless you scaled up. It's still the same value creation process whether supplemented by technology or not.

We use technology to process information both for customer facing applications and as an internal set of applications. The public facing internet has different goals than the privately controlled enterprise networks and that has been the source of contention in the adoption of social media marketing in business I believe. The operational tension of trying to adapt a technology for the customer while maintaining control and stability of an internal system has caused some traditional IT system thinking people to ban social network access entirely. But I'm getting ahead of myself.

Certainly, what I am breaking out here is not going to be a Web 3.0 design because there are people who talk about all these pieces already, but the structure that I'm putting it into is unique I think. I'd like to have any comments where you think I just reinvented the wheel of course. For me, it's a new set of ideas that came out of grasping SOA concepts and seeing ITIL deal with our social channels from a high enough level that it didn't matter whose definition of any 1.0, 2.0, or 3.0 term was right. The progression of technology assisted asset complexity is as follows:

• local information only
• local information and applications
• shared info
• shared applications
• shared info and applications

Information and applications


Web sites were originally created to distribute files of data. The idea of the web was that of a giant file server that everyone could access. This took the place of the employee who wrote down or handed a pre-printed piece of information for every customer who walked in the business. Now it was publicly available and employees could direct a customer there.

The employee generally wanted to capture and record some customer information to process a transaction so they asked questions, made phone calls, and consulted managers to take care of the sales process. The employee also might want to automate how they did surveys and updated information to display. These types of automated processes were placed on a web site also.

The two types of assets, information and applications, have been at the core of the value transfer system of business before it was automated when it known more as knowledge and process. Now our automation of the two is maturing at a level on a large customer scale. And startups are first out of the gate to take advantage of lowered costs of entry for these assets. Other asset types in ITIL terms such as capital, infrastructure, organization, management and people have stayed more stable but have had to adapt as the needs to integrate with information and applications have changed. Entrepreneurs who understand customer development and lean startup ideas from Steve Blank and Eric Ries have the upper hand here. Their management concepts are based around information flow on the customer side and a more efficient process.

Local info only


The first telephone call was a shared piece of data. The first web site was a shared piece of data.. But we changed our common communications model from a one-to-one to a one-to-many through the use of technology. That made the barrier to entry financially lower for distributing information. Inside the enterprise, the same shift happened when a corporate database was built allowing any employee access to company information.

If you as a customer wanted to know something about the company that was stored in the database, you had to use an employee to allow you access. In a small business, they might look up the information in a Word or Excel file. The web site became a substitute for that employee as distributor of that information and that customer inquiry process became automated

Local info and applications


Programmers very quickly began exploring how they could add process or logic into the data that was on the web. SSI, SHTML, CGI and other basic ways to augment the display of data were developed. People today, still create these basic types of sites first full of data, and then progressively adding e-mail and lead acquisition functions. But the quantity of web sites now available have made the usefulness of these walled gardens less interesting unless they develop a massive amount of data and make it available through a great interface.

The corporate DBAs found that by adding stored procedures, it allowed them to better manage their data. COBOL and other languages were designed with database access in mind and database management systems developed GUIs and created languages to allow better access and management of their data. Now in the enterprise, the systems have grown into data directly accessible to the employee called content management systems (CMSs) and the data systems that manage more structured data requiring applications to make sense out it all.

Shared info


Networks allow for communication and the idea that data didn't have to be all in one place created some advantages but created severe problems as well. For the corporate data schema, it was generally better to keep data in one place under a central control but the distributed database system evolved as businesses found efficiencies to take advantage of.

It was much easier for the web site to link to another piece of data on another web site creating the distributed database called the world-wide web. But without a central control, it lacked usefulness as information increased. Google provided a simple interface to the web but without meaning. People are still trying to turn the web into a giant library complete with a Dewey hexadecimal Semantic Web indexing system or something.

Shared applications
Distributed applications started to appear as the efficiencies emerged for managing logic in different places around the corporate network. One file might have been partially processed on one server and then passed off to another to complete the processing in a batch job. Now packets of information are being passed as messages around the corporate network for processing. These packets can be managed my smaller applications known as services and on the web these services become accessible as web services. Managing the data being handled by these services and the architecture orchestrating it became known as Service Oriented Architecture (SOA).

On the web, programmers started accessing other web sites applications and combining the outputs of them to create a web site that had no data of its own but provided value in seeing property values or crime statistics
on a Google map. These kinds of distributed applications were called mashups. Even without several web servers contributing their applications to one web site, a web site could enhance the logic on the web server with logic on the browser using JavaScript's AJAX and formidable language powers rediscovered after its shameful use by direct marketers in the past.

The shared information or shared applications models by themselves were the beginning of a social transformation of the web from single managed to multi-managed. The first social users of the web were programmers who collaborated on how systems should work together on the internet. But the ability of common folk to participate in this sharing wasn't available until the administrative structures were programmed by someone who wanted to automate the sharing.

Shared info and applications


The web initially started with basic interactive applications such as MUDs and bulletin boards which became forums but the techies were satisfied with just having fun. Later the push for business use of those same functions created more socially useful applications. Now the business use of social networks is what people are talking about mostly because there's money involved.  These sites provide customer access, shared data, and shared services across multiple sites bringing together Twitter data, Facebook profiles, publicly accessible blogs, forums, news sources, and whatever else sites can get their paws on.

But the enterprise has trouble dealing with this level of interaction while maintaining control. The large scale enterprise resource planning (ERP) applications are large and complex beasts. When many people are adapting and self-managing on the web to market interests, the change is rapid and without disaster as long as you don't look at fail whales and massive hacks. When the corporation manages an ERP adoption as a single project, the results often are poor. Other corporate systems are striving to grab public data and integrate it with internal information in new types of applications such as the social customer relationship management (SCRM) systems.

I'm thinking that the corporation needs a new standard for this social and enterprise level architecture. I'd call it Socially Enabled Architecture (SEA) and it would answer the strategic questions of

• how does a business monitor social media?
• how does a business engage with customers through social media?
• how does a business record that social data?
• how does a business share that data?
• what social media makes sense to capture?
• what relationships are useful to capture?
• what application types manage social data the best?
• what processes best manage social data interactions?
• what metrics should be used to determine social task successes?

Social assets


Value comes by assets and finding better ways to share those assets. We now are sharing more of our assets than ever before in business both of information and applications. Consumers now find that the barrier to entry is so low on business assets that they easily become a service of value when they start blogging or tweeting. Upgrading that to a web site with more data and applications to take the weekend socialite to a business venture takes more understanding of customers and business in general. But the home-style web business is growing because of that and the future looks to continue the trend. Myself, I'm looking forward to more mature SEA web sites in the future.

Image by JW_00000 via Flickr

Related articles by Zemanta

• 10 Ideas For Web of Data Apps (readwriteweb.com)
• Enterprise 2.0: It's Still All About People (socialmediatoday.com)
• Top 10 Enterprise software for Startup (taragana.com)
• Introduction to Service Oriented Architecture (slideshare.net)

More action, less talk.

Image by doryexmachina via Flickr

I've been disengaged from socialized networks somewhat and deep diving into some new developments in .NET code recently like WebFormsMVP, IoC, and an OODB(db4o). So much to keep up on. Also I'm applying the ITIL strategy info from my recent blogs to a real case study of service management. It's important to me to do first, and talk later. But being a teacher, I'm paid to talk and it's a luxury to be able to work out the theory into reality. More soon.

Focus on the customer to optimize sales. Learn their value.

The way to see value is in the customers’ eyes. Value is not the sum total of the technology parts you assemble with the profit you need. If the customer demands it, the price can rise as long as the supply stays constant. This is a basic economic fact. The customer demands better social networks because they see value in it. When you start using the customer as the vantage point you start understanding value. The objective is to increase value in the customers’ minds. Then your sales increase.

This is the last in a series of five posts which has covered value through the help and guidance of Information Technology Infrastructure Library. Past posts included:

• Sell me quick with your value. Wait, what’s value? (Definition)
• Maximize value for your customers or they’ll leave. How to get more. (Utility)
• Promise me value or your sale is toast. Warranty in value.
• How to not lose value across the great marketing divide. Be the customer.

Listening to customers

It takes effort to keep listening to the customer and not just be the prisoner of your own process. Shift happens. Businesses have to stay nimble and look for the next big thing and be prepared to drop the thing that isn’t doing the least good to retask those assets. The business, which could be you if you have a blog, tweet, or keep up a web site, must know when things like the floppy drive have run their course and people need something new. Steve Jobs was listening as he transformed the interface of the desktop computer.

People will lie to you about what they want as the last post talked about. We lie to ourselves just as easily when we’re the customer. Customers talk up the features that they want and then realize that it was a benefit they really needed after they have it put in front of them. It’s because we think in concrete units easier than in abstract needs. Perhaps the most famous quote on this subject was Henry Ford who supposedly said:

If I’d asked my customers what they wanted, they’d have said a faster horse.

Lazy manufacturers

Let’s update a saying that Peter Drucker, one of my favorite business writers, has used. He said that there are no irrational customers, only lazy manufacturers. Drucker was the force that helped turn the focus on the customer wherein the power of success laid. That customer now has recently been empowered with the internet and took over the wheel causing the shift from sales as we knew it to Sales 2.0, or sales that doesn’t work the old way. The customer has to be assumed to be rational but as Drucker knows, the perceived reality is usually quite different from that of the manufacturer’s reality.

The new saying should be that there are no stupid customers, only lazy service providers. That goes for Google, Microsoft, Oracle, Apple, Twitter, Facebook, and anyone else who lets the customer slide enough to where they have to find another product or service that really meets their need.  The laziness is in not keeping an open ear to the customers’ needs.

Growth can slow efficiency

You may be listening to the customer and then charging off into the distance where the customer may follow or may not. They are the leader here and not you. If you start ramping up a bigger and better product, you may be in for some rough times ahead. The not so stunning introduction of the iPad is one of those make-it-bigger thoughts that equates to making it better in executives’ minds. A bigger iPhone is just a more unusable iPhone. The iPad is just a newer type of computing device that lies somewhere between the smartphone and the netbook. Most likely, there won’t be a separate market develop for it but it may cause the netbook market to go towards touchpads faster. Prove me wrong, Apple.

Size increases can provide the brakes on the efficiency of a firm as well as a product/service. Ben W. Heineman, Jr., former general counsel of General Electric, complained that being big is not the solution to superior legal service, quality or price. In the end, Heineman “came to believe generally that small was beautiful, and big was wasteful.” The problem he was grappling with was one of outsourcing and therefore loss of control for global in-house law departments. He preferred the small specialty group in-house over the global legal powerhouses. The extremely large law services didn’t see the need of the customer to be in control and how much better small groups served the corporation.

So what happened to the economic principle of scalability? It works to a point which is more of an issue of the industry rather than a universal principle of growth. The service manager has to be aware of when size gets in the way and step back into guerrilla tactics instead of keeping up the full assault.

Value comes from turning towards the customer and giving them both what they need and a promise of stability. Value is more than a good product at a low cost. And throughout the quest for more value, you will never achieve the goal because it’s a journey that will keep your ear open to the customer who really makes your business or service work.

Image by Magnus3D via Flickr