Close

Information Risk Management: 

Microsoft Office 365, Microsoft Teams, Microsoft SharePoint Server, Microsoft SharePoint Online, Microsoft Exchange Online, Azure DevOps & App Services, Azure Machine Learning

The InfoPath Conundrum

John Holliday

November 17, 2014

Is InfoPath dead? We must still deal with data capture, data storage, data presentation and data processing in order to build real systems, but the technologies involved within each stage are constantly evolving.  Maybe the future isn’t about forms at all.  Maybe its all about function.
Table of Content

InfoPathFormsQuoOnce upon a time, when InfoPath was the “new kid on the block”, you could almost taste the excitement in the air.  “Workflow” was the hot topic, and the industry was abuzz with possibilities.  The whole idea of managed content lifecycles and controlled information pathways through an enterprise really captured the imagination and suggested a fundamental shift in the way we deal with information.

I must admit I was hooked on the fundamental architecture of the InfoPath form designer.  The notion that one could define a detailed schema that prescribed the precise rules that govern a given set of data elements was truly compelling.  Using this approach, one could then wrap the schema with a design layer that could capture the rules governing how users would ultimately provide that data.  You could then take it a step further and wrap that with an abstract processing layer (i.e. SharePoint) that would govern how the data would be used.  Wrap it again with a server-side presentation layer (i.e. SharePoint) that would govern how users provide the data through a browser.  Wrap it yet again with a storage layer (i.e. SharePoint) that would govern how the data should be stored, and again with a security layer (i.e. SharePoint) that would govern who could access the data, and so on.

The point is there are many “paths” that information follows as it flows through the real world, and there are equally as many layers of technology that must be applied to the core set of data elements defined in the schema before we finally arrive at a reliable (more importantly, manageable) set of components we can actually work with.  But the basic concept is still viable.  Define the schema, and then use it to capture, distribute and process information.

So, are we still talking about “forms”?  After all, we must still deal with data capture, data storage, data presentation and data processing in order to build real systems.  But the technologies involved within each stage are constantly evolving.  They are changing so fast, in fact, that even Microsoft couldn’t respond quickly enough to meet the challenge.  Hence the demise of InfoPath.

So what does this mean for the whole “Forms Services” paradigm?  Now that Microsoft is officially deprecating InfoPath forms in Office 365 (see the Update on InfoPath and SharePoint Forms), what will the “information pathway” look like in the not-too-distant future?  Will we have to revert back to Web forms?  Probably stuck with them for quite a while.  What about Access Web Apps?  Interesting, but no workflows, and issues with publishing and security.  Excel surveys?  Limited functionality.  FoSL (Forms on SharePoint Lists)?  Platform specific.  Structured Documents?   Same.  Cloud-hosted forms processing?   Is there still a need for a standardized form designer application at all?  I’m still a huge fan of schematized XML for building solutions.  I like the idea of focusing on the underlying data structure and then letting the tool generate the scaffolding needed to capture the data and move it through the workflow.  Wait.  There’s that word again – “workflow”.

So why did InfoPath fail?  The answer lies in the basic reality that inspired the product name in the first place.  Information flows through an organization and follows different paths, depending on how that information is processed and consumed.  The problem is that there is an ever-increasing number of ways to capture, process and store information.  And it's not just about form-factors.  It's about people and processes.  It's about reporting and BI and content generation and security.  In short - it's about nearly everything we do.snowballstuck

I like the approach that Nintex, formotus, FormsQuo and other vendors are taking with their centralized, cross-platform forms engines.  But we’re still waiting to see what direction Microsoft takes with Azure and Office 365.  Ultimately, we're going to need a new paradigm.  One where the data capture mechanism (i.e. the "form") is synthesized automatically from the context in which the data is produced and consumed, and the data already captured.

Imagine a snowball picking up people and data and metadata and content as it gathers momentum on its relentless trek through your company.  Like that, every packet of information we encounter as we work through our inbox starts out small and then acquires more and more detail and significance as it moves from one context to the next, igniting various processes along the way.

Maybe the future isn’t about forms at all.  Maybe its all about function.

My 2 cents.

Share on facebook
Share on twitter
Share on linkedin
Share on email
Share on print