Emergence of HTML5: Unlimited Possibilities for App Developers and IT

Last few years have been highly significant and eventful for the app developers and IT professionals in more than one way.  PCs were dominating the personal and enterprise computing spaces for the last 2 ,3 decades.  Even now PCs are not going anywhere and enterprises are not going to dump them in the near future at least. But what about the personal computing space? 

Smart phones and tablets have successfully entered our drawing rooms, if not the bed rooms and rest rooms.  After giving the PC a run for its money, these mobile devices have started helping people solve some of the light weight enterprise problems as well. That's the reason all CIOs are carefully watching the BYOD movements and no one can afford to say an unconditional 'NO' to these personal gadgets. These disruptions in the technology world is characterized by some industry-wide events and trends that are not under the control of any individual or even one big technology corporation

• When the PC revolution happened, there was one Goliath, one OS - Microsoft and Windows. Now there is no monopoly

• Though the smart phones era was started effectively by Apple, they don't command more than a decent a market share

• Openness of Android has enabled even very small, local hardware makers to come up with 'world class' mobile devices though Android itself has so many security vulnerabilities for exploitation by lip smacking hackers.

• Mobile platform market is highly fragmented between many players and none is having the brutal power that Microsoft once wielded on PCs

• Microsoft was directionless and confused throughout -where their sweat spots reside and  who are their primary targets? individuals or enterprises?   

• Consumers are not ready to pay for the personal computing software- be it a tax calculator or a personal organizer or even Angry Birds

Confusion for Developers and IT

Now the biggest question facing individual developers and IT departments is what's their choice when it comes to app development?

• What will they develop for- desktop or web?

• If desktop app, will they need to support mobile devices as well?
• If I develop a windows desktop app, can that be made device independent with relative ease at affordable cost?

• Do I need to worry about the Chrome OS if I choose desktop app or am I fine with worrying about Windows alone?
• Do I need to embrace the highly touted 'Mobile first, desktop next' mantra?

• If I develop a web app, which technology should I go for? Windows friendly ASP.NET or Java technologies or open sources like PHP or Python?
• Can web apps be truly platform and device independent?
• Can the web apps provide true native app experience?

There are many questions no doubt, but is there a solution or a combination of solutions? I am not too pessimistic because of the presence of one open standard: HTML5

Emergence of HTML5

Though HTML5 is the next and the latest version of HTML, it's more than just the next version. HTML5 not only provides you just mark-ups unlike the earlier versions, but a lot of hidden scripts and functionalities behind those mark-ups. It would be an injustice to call HTML5 a mark-up language; it's a web technology.

There are so many web technologies, HTML5 stands out from the crowd in that it's emerging as an industry standard promoted by W3C. More importantly all the major web technology vendors have pledged support for HTML5, actively taking part in developing the standard. All the major browsers have started supporting HTML5- Chrome and Safari are front runners; IE, Firefox and Opera are catching up. Reality is if the browsers don't support the HTML5 standards, there are high chances of getting dumped and losing the user  base.

Why HTML5 is important for developers and IT?

These are early days but chances are bright that HTML5 emerges as the de-facto app development platform. HTML5 itself is not a complete standard as of now and no one single browser is supporting the available standards 100%, though Chrome and Safari are very close. Not many real time, complex apps are developed in HTML5 yet. Notwithstanding all the above facts, HTML5 have started answering a lot of questions the technology community and IT are facing

• If you decide to create a web app now, HTML5 is the most preferred technology because it's cross platform, cross device
• If you decide to create a native app, HTML5 will still be an option. There are many open source packaging tools that compile your HTML5 app for the native platform- be it Windows or Mac OS X or Linux.
• You shall switch between web and native with relative ease as per the business and user community needs with just one codebase 

How the packaged native HTML5 app works across platforms? As long as your platform has a browser engine that supports HTML5, it's good enough to run the native HTML5 app

• If you have Chrome or Safari, then you have the WebKit browser engine by default (WebKit is the powering engine for countless number of browsers)
• If you have IE, then you have Trident browser engine

• If you have Firefox then you have the Gecko browser engine

All these browser power houses are supporting HTML5 in varying degrees. In future, you would only expect that the compliance  to grow till they catch up 100% HTML5. So it's safe and wise decision to embrace HTML5 whatever may be your app development needs.  Following facts make the choice more obvious

• With HTML5, you shall target PCs, smart phones and tablets all at once. With proper architecting, you may do so with a single code base

• Microsoft's windows native app options are confusing as of now- No updates for Windows Forms and WPF for the last 3 years. WPF got an update only in 2010.

• You can even build the Windows 8 Metro apps (also called Store Apps) in HTML5.

Without hype, it looks like all the roads are leading to HTML5- be it a consumer or enterprise app, web or native app, PC or mobile app. It's a welcome change from the skills perspective, you don't need to learn too many technologies that all finally accomplish the same. Instead you can focus your effort and energy onto something useful for the betterment of our lives 

How RESTful services stand out from other web services?

There have been a handful of approaches and technologies for accomplishing application-to-application communication. On the Microsoft stack itself, you had COM/DCOM, .NET remoting, ASMX Web Services and WCF Services, just to mention a few that I know. Other platforms supported countless technologies that tried to communicate across machine, network and platform boundaries. Standards start evolving naturally when the number of choices gets beyond a point of imagination. That's how web services started flourishing as an industry standard for app-to-app communication and provided the much needed platform interoperability

Every name worthy technology supported  web services that are based on SOAP or WSDL . In particular, SOAP based web services wrapped the business engines of complex enterprise  LOB applications. Any other app that wants to communicate with the enterprise app must know how to deal with the SOAP web service, means the client environment needs to support SOAP toolkit

Web like Communication

When everybody thought SOA and SOAP web services are here to stay, the industry started shifting in a direction that leveraged the good old HTTP protocol . That is, design your services in the same way web or internet is architected. HTTP is the basic protocol of web. SOAP web services use HTTP protocol, but they are not architected in the way web is architected.

The concept of web is quite simple and intuitive. All that you need to know is the URL (URL is just one part of the URI that uniquely identifies a web resource). If you just know the URL, it's enough and your browser will take care of the rest. Technically it means that your browser has invoked any one of the HTTP's basic methods like 'GET' or 'POST' or 'PUT' or 'DELETE' on the unique web resource, for example 'index.php' of https://facebook.com

Now apply the same principle to your service. Your service is given the URI and the operation to be performed on the URI. Your service executes and sends back the response. Your service is now called "RESTful".  In simple terms, web style architecture enabled user-to-app communication through browser. With RESTful services, the same web style architecture enables  app-to-app communication but without browser

REST and Real Life

There are many advantages with REST style. One thing that stands out, in my opinion, is the creation of uniquely identifiable resources. URIs were traditionally seen as pure web resources like index.html, home.aspx, homepage.php, MyPhoto.jpeg or Something.xml. These are physical files living in the drives of web servers. REST is resource oriented and shows the resources in different dimensions. The URIs are no more pointers to physical files on a web server, they can be anything and everything. An URI shall be a pointer to a real world object like a customer, a PO, list of products manufactured by a company, a linked-in or facebook profile or my Maruti Swift (Vehicle Identification Number, VIN)

If the client needs the details of my car, all that needs to do is to send the URI that uniquely identifies my car.

http://maruti-suzuki.com/swift/<vehile-identification-number>

Right way to think about this is, if the client is an app then it receives the details of the car in the format wanted by the app. It's for the app to do whatever it wants to do. If a browser sends this URI then you get to see the details of the car in the browser window. Hence for every identifiable resource there is a web UI (obviously it's dynamic) and a web API.

RESTful services force people to coin URIs for every object worth identifying. There could be billions of URIs, transferred between people and apps.

You want to suggest me a book, all that you will do is send me an Amazon URI that uniquely identifies the book.

You want to recommend me a person's profile, you will send me a Linked-in URI that uniquely identifies the person.

In future there may be QR codes that will just contain the URIs displayed on shop bill board or in an advertisement hoarding. You will use your mobile, scan the QR code, gets the URI and the 'REST' is obvious. Like this there are many different business cases.

But the key lies in creating a URI for every object that deserves to be identified. Once done there are unlimited possibilities. This is where REST scores better than other web services by leveraging the WEB architecture

How much documentation is 'Just Enough' Documentation?

'Just Enough' is a very catchy phrase in the agile world, with every other noun is prefixed by 'Just Enough (JE)'. Sure you would have come across JE requirements, JE design, JE up front architecture, JE documentation and so on. Big problem with JE is nobody knows how much is too much. Most interesting of all is JE design documentation, if you ask 10 people you will have 10 different answers. Both the traditional advocates and agile proponents are guilty of manipulating the 'how much of design to be documented?' question to their whims and fancies.

Traditional Approach to Design Documentation

In the waterfall projects, architects use to come up with 200 pages of design doc or a flurry of UML diagrams only to see that they become at least slightly out dated even before the first line of code is written. That's because the architect worked in isolation and didn't collaborate with the development team while creating the design and document. When the development team starts coding, they are confronted with a few practical problems that the document is completely dormant about. When the design doc doesn't answer questions, they just keep it aside. This is the situation the day coding starts. Better not to talk about the design documentation the day coding ends. Design and coding would have gone just like a divorced couple, on 2 opposite directions.

Architect will say that's the development team's problem and they don't know how to implement my design. Development team never cared the architect or whatever she says in the design document. Finally the single version of truth is your code only ; People who join the project mid way or who maintain the software will have to start from the code doing reverse engineering.

Not to say that if you have a big but 'live' document, you can conquer the software easily. It's still a combination of many factors like reading the doc (Just Enough reading??), walking through the code and collaborating with the existing or old team members. Sad reality is these 3 factors never meet eye-to-eye

Agile Approach to Design Documentation

Agile proponents are equally guilt. Of the 4 declarations in the agile manifesto, they like one thing for sure- "Agile values working code over comprehensive documentation". This is great, but the problem is how the agile teams understand and interpret this. They interpret this as "Agile values working code over documentation". Result is obvious, there will be zero documentation. You will have only code- no matter whether you are from business or IT. That's not a great situation to-be in either.

Do we need to strike a balance?

A few high level diagrams would always be helpful. The chances of the documentation becoming obsolete are very remote because they are at a "high level". Capturing the big picture is mandatory for any future reviews and understanding. Following approach may help

• One "all-in-one" systems diagram in which you depict all the other systems and users interact with your software. This will be great for business people and some one who just starts with your software

• One Components diagram in which you depict all the components of your systems and how they related to each other. Your software system may contain a smart client app, a web service and an admin web interface or an unattended windows service. You put them all in one diagram showing the inter-dependencies and relations. This will be useful for "tech savvy" business people besides hard core techies.

• Class diagrams for each component in your system- this will give a great deal of information to  techies who are going to maintain the software

Apart from the 3, you may go to lower levels of design documentation depending on the complexity and/or maturity level of your team. But mostly lower level design documentation is a wasteful exercise because it will get outdated every other day. With concepts like refactoring and automated unit testing, it's almost next to impossible to keep the documents 'live'

More over with too much lower level design documents, you treat your developers not like developers, but as "Code Entry Operators" which no developer likes. One practical approach is each team defines their level of design documentation for their project and they adhere to it. "Just Enough" is always to going to be subjective, but we may conquer it with some pragmatic approaches like capturing the big picture as we discussed above

Are you a Solution Developer or a mere Service Provider?

You might be remembering the famous iGATE campaign nick named as 'iTOPS' in 2012 that promised the customers of business outcome based billing rather than the 'flawed' time and material billing that just takes into account the effort spent rather than the business results. Though the campaign may not be popular with IT service industry, I definitely see value in that concept. Customers, stung by the one recession after another (starting from the US sub-prime housing loans in 2008 to the recent Euro crisis), are increasingly looking towards cutting costs. When it comes to cutting costs, their first target would naturally be IT budgets unless IT is the enabler of their core business model itself. (think of Amazon or Paypal or eBay). It was a known fact and confirmed in a recent survey that IT service companies are doing much better than most of their customers

In the good old happy days IT service providers milked money on time and material contracts without worrying about how their customers are performing in their industry against cut-throat competition. It seems like those days are numbered if not over already. While the IT companies will fight this trend at many levels and dimensions depending on their size and capabilities, what it means for individuals like us- developers, testers, managers or architects?

Am I capable of providing a solution to my customer's problem(s) or am I capable of just coding or testing or designing? It requires a fundamental shift in the way we think and engage the customers. Currently even for a small business problem, we require a PM or BA to talk to the customer to understand the business context, a developer to code and a tester to verify the functionality. Most of the cases the PM or BA is engaged not because the domain is overly complex, but the technical team is simply not capable of communicating with the customer.  A job ideally done by one person is split between 3 people to fill-in for the gaps in the team. Essentially this leads to cost escalation and the customer bears this overhead (in most cases) or the project never takes off due to cost constraints. (that means the customer learns to live with the problem, which is very bad)

Instead if we have molded ourselves as a Solution Developer rather than a coder or tester or technical specialist, we would have given a solution to the customer's problem - not a software product or worse just services. No doubt any solution is a result of a product + service. But then a product or for that matter any service on its own is not very useful. Even after you deliver the product or service, the customer may still be devoid of a solution to her problems. Benefits or compensation will be increasingly linked with the results in future. An electrician or a surgeon or a software engineer is paid for fixing the problems or providing a solution and not for spending effort.

In the coming days, 'Solution Architect (SA)' will be the much sought after role in the IT. SA shouldn't be thought of as technical architect or a senior technical person, but anyone who fits herself into the shoes of the customers, appreciates the problems of the customer and sees that a solution is delivered. Are we up to the challenge?

Process Definition at the Project Level

We hear and encounter a great deal of lack of process adherence in the IT industry, particularly in the projects execution sphere. Most of the times, process audits are  nightmares for project teams and people have the habit of 'PREPARING' for the audit after the audit schedule announcement. This is not the case only with small or start-up shops where processes might be managed in an ad-hoc manner.  Even the seasoned biggies, who boast of numerous process quality certifications to their credit, are suffering from the disease.   This disease is highly infectious and creates bad blood between the QA and project delivery teams, often leads to individual/team frustrations and worse organizational politics.

In the past various attempts been made by stalwarts in the industry to regularize/de-regularize the process framework structures so that one eliminates the overhead, improves the compliance level and by the way increase the business value to the customer (if at all possible :))

ISO

ISO failed to make a cut with the industry mainly because of the fact that it's a generic standard and has nothing to do with the industry itself. When your process framework is agnostic about the industry, it becomes a dark box and nobody understands what it does to improve the process quality, business outcome and ultimately the value for the customer. Naturally many IT companies that have ISO are shying away from even publicizing it.  Many are considering an exit

CMM Levels

CMM was addressing a whole gamut of problems with generic standards because it is industry-aware. Still the situation is more than chaotic- one project in level X, the other in level Y, fudging of records just before the audit, meaningless documentation, "project success but customer unhappy" scenarios and lack of inspiration about processes and audits. What could be the problem?

Agile processes came and improved the situation overall because of the insistence on team buy-in and team empowerment. They took the processes closer to the teams. But is there something missing yet?

I think so. I don't think there are problems with different process elements themselves, but at what level they are defined.  The best way is to 'Define the process elements at the project level'. Why is it so important?  Because

Every project is unique- in terms of objectives and requirements;

every customer/stakeholder is unique - in terms of expectations out of the project;

Every IT eco-system is unique - in terms of infrastructure flexibility and SLA agility;

Every project team in unique - in terms of cohesiveness and collaboration needs;

Needs of an application development project never matches with an ERP implementation or a Business Intelligence initiative. 

Defining processes at the project level is not something new, in fact, most frameworks and organizations optionally allow this. The point I want to emphasize is- it's not optional; it MUST be defined at the project level and team buy-in for the defined processes is very important for razor-sharp compliance.

One size doesn't fit all. One process framework for the business division or the organization or the whole industry is absurd. Let's NOT deceive ourselves by believing that processes defined by one set of experts, written once upon a time within in the comforts of an air-conditioned room are going to help our current project too. We need a very pragmatic , down-to-the-earth, fresh process definition that MUST happen at the project level, not even one level above (say, Program level).

Let's treat each project as unique one, let's involve the project team and the customer in the process definition, tailor the framework to fit your unique needs and embrace success. Happy projects!!! 

'IT Consulting' as a Profession

Despite the number of techies that India produces each year, India's never been a hub of innovation in the IT sector. In the TV debates and NASSCOM surveys, it's always blamed on the lack of suitable eco system in the colleges and universities. It's been told many a times that an average Indian techie takes 3 years before he becomes fully 'employable'. But what happens after 3 years? What the companies are doing about creating the right breeding ground for innovation?

In 3~5 years time, most of our techies become either 'Leads' or even 'Managers' in some cases (Halo Effect??). The average time period a Software Engineer (SE) remaining technically hands-on is mere 5 years. Is that the right timeframe for becoming an expert in any domain?

Investment Banking is the domain that is always accused of wasting highly brilliant minds onto speculative trading and the technical analysis of the stock pricing trends. Their talents are not utilized towards the betterment of products or services that add immense value to the society like an innovative solution for improving the health care. Indian IT service industry is doing a similar mistake by promoting people too early to managerial positions, thereby taking a hit on the technical caliber. Naturally India is very low on the IT value chain. High end, innovative IT requirements are done mostly in the USA and only the work that sounds like 'back office' comes to India. Spiraling effect of remaining in the lower end of the IT value chain is that we need to face competition from countries like Indonesia and China.

Thinking about the problem, it looks like that 2 things need to happen very quickly

• IT giants should leave out the 'quarter-on-quarter growth' madness, instead  spend more on R & D, inculcate the habit of giving it back to the industry (and the society as well) by regularly coming up with ground breaking innovations.

• We cultivate the culture in our SE's that IT consulting is indeed a profession. A SE can very well remain as a SE throughout her career accomplishing great technical things and prepared to exit the industry as a Senior Software Engineer or maximum a Technical Architect

The second one is easier said than done because that encompasses a cultural shift. We should attack the mentality that becoming a Manager is a 'promotion'. Teams should have a truly flat structure. A group of senior SE's shall be managed by a Junior Manager and the SE's pay packet shall be bigger than their Manager depending on the SE's experience and expertise level. People who have the technical caliber should be protected for large, complex technical engagements whereas people that show brilliance in managing projects/people should be handed-out a career in the management . Just like a Doctor or a Lawyer does, a SE starts and ends her career as an SE. A Manager starts and ends her career as a Manager.

I understand there will be cross-cutting requirements like 'We need a great PM who understands BI/DW' because experience has taught us that people who are knowledgeable in the domain go on to become great Managers. Here the catch is 'great' Manager and 'understands' BI/DW. We don't need a BI/DW expert to become the PM, all that we require is a great PM who 'knows' a bit of BI/DW

In the medical field, India is becoming a consulting power house, it attracts people from all over the world just to consult our doctors. New terms like 'Medical Tourism' is gaining ground. What did the trick here? Because Doctors treated it truly their profession. The number of Doctors who went onto manage different things like the operation of a hospital is very less. Hope the same happens for IT consulting too

Can DevOps culture flourish under out sourcing?

DevOps is the culture in which the development teams partner with the operations/IT for the purpose of seamless integration of development cycle through to the implementation and continued operations. Though tools and processes (For example, agile processes show your 'DevOps' intentions) help DevOps, it's the cultural aspect of DevOps that is considered most important than those tools and processes. That cultural aspect makes it difficult and a dampener in many organizations for better adoption of DevOps.

In the ideal world, developers support the IT guys by making provisions for diagnostics, performance, load testing etc. early in the development cycle itself. Operations people support developers by giving quality feedback about users, their behaviours  features the users like most, exceptions etc. in a timely manner. Some automation is a real possibility in this area, but still if the organization hasn't caught up with the DevOps culture, returns from these automations and tools cannot be large.

Some of the DevOps Dampeners

• Silos within the organization spoiling effective integration between the development and operations
• Lack of product ownership (to some extent lack of agility)
• Politics, blame game etc. (Dev throwing it to QA and QA throwing it to Operations and Operations finding nowhere to go)
• Out sourcing development under Fixed Price contracts

First 3 points are obvious and a systematic overhauling of the organizational culture can only address those issues gradually (there cannot be quick fixes for cultural issues though). But the fourth one is a business decision and it's very difficult to stop because of the cost arbitrage regimes that we are operating.

Out sourcing the development work to an external group, that too under a fixed price contract would be a big setback for the DevOps culture. In a fixed price service environment  the service provider earns their margins by efficiently utilizing the resources and giving the bear minimum as defined by the statement of work (SOW). Under these conditions, it's very difficult to expect the DevOps culture to flourish. Support to the operations team is governed by the warranty clauses and subsequent AMCs (Annual Maintenance Contracts) and not by team spirit and ownership

It's very difficult to encourage the DevOps culture under the contractual culture; that's why the agile proponents preferred customer collaboration over signed contracts. So the question is if it's mandatory for the DevOps to die under the out sourcing contractual environments?

I am a born optimist and I still have some hopes.

• Customers will have to evaluate the service provider and establish trust with them through initial pilots.
• Once that trust is established, they need to treat the out sourced development team as their 'own virtual' team.
• Since the trust is established, the customer should focus on collaboration over the signed FP contracts.
• Constant traveling of Dev team members to customer premises and customer operations staff to the development houses as CBMs
• Processes and tools must be used to bring about the trust
• There has to be a separate SLAs between Dev and Ops but not in the form of signed contracts but mainly as team norms