Cloud Inside

I’ve just written a Go Faster plan that will allow HarrisData to re-engineer our entire enterprise application portfolio – including HRIS, ERP, and CRM applications – into next-generation web applications in a matter of months

Why risk a complete re-engineering of what already works? Not so long ago, PC World named the original Sony Walkman (with the cassette tapes) as the greatest gadget of the previous 50 years. Yet Steve Jobs and Apple created the iPod (#2 on the same list) about 20 years later to replace what already worked. A comparison of the two shows both how similar they were, and how different in terms of scale and flexibility. The Walkman offered a theoretically unlimited song catalog (by switching cassettes that held about 36 songs each), had replaceable batteries, and played Beatles music from the beginning.  But even without the phone or the apps, the iPod offered the ability to store and play thousands of songs in a smaller, lighter device  – revolutionizing portable music. With virtually limitless access to Internet-based music catalogs (for a fee), these portable devices and their peers have transformed the entire music industry in a little over a decade.

Enterprise applications are due for a dramatic increase in scale and flexibility as well. They need to leverage the power of the Internet technologies that run the world’s biggest web sites in order to manage the massive amount of enterprise data that needs to be captured and mined to improve business performance. However, faced with the prospect of re-engineering their entire software stack and replacing millions of lines of java and/or C code, many vendors are unwilling to take the next daring step. To take that step, its time to put the cloud inside the application.

What does it mean to put the cloud inside the application? It means that enterprise applications need to be built to leverage what works on the cloud from the inside out. Vendors that are trying to keep up with the web are scrambling to add SOAP and REST APIs to their existing products. They believe that the massive, tightly integrated applications they developed 20 years ago need only be connected to the world of the web to gain the (marketing) advantages of being ‘on the web.’ The approach is not unlike the efforts to use ‘screen-scrapers’ to make applications look like Windows applications over a decade ago. This saves them from having to re-examine and re-write millions of lines of java and/or C code, but prevents them from taking the big step forward. Breaking the enterprise application into independent web services and loosely coupling them through resource identifiers enables the next generation of enterprise applications to scale and grow in ways unimaginable to the prior generation – in the same way the iPod seemed magical to those who owned a Walkman, even though it accomplished fundamentally the same task.

AppsInHD™ delivers this kind of loosely-coupled set of enterprise web services that are woven into applications by the resources that are defined to them.  AppsInHD fundamentally uses REST and its emphasis on resources (“pieces of information”) to create a network of services which work together. The AppsInHD network is defined in a way that allows new resources to participate in the network of services simply by defining the resource and any unique behaviors. To develop new applications, we design the resources (“pieces of information”) unique to the application and any actions unique to the resource, and deploy the application through AppsInHD. The Go Faster plan now focuses the work on application design, with coding, documentation, and testing phases focused and minimized to the unique facets of the resources in the target application. Watch carefully and see how fast HarrisData rolls out applications based on AppsInHD. 

Posted in AppsInHD, Cloud computing | Leave a comment

Go Faster

I’ve written a lot of strategic product and marketing plans over the last 30 years, and I just wrote both the most challenging and most enjoyable yet. It’s a simple piece called ‘Go Faster’. After a successful rollout of our first application based on the new AppsInHD enterprise application software platform (HR/Payroll), I had meeting after meeting with excited customers, partners, and investors asking me how we can get all HarrisData enterprise applications – including ERP and CRM applications – delivered on the AppsInHD platform as soon as possible. We had an aggressive plan to do so, but aggressive was not good enough. We had to go faster.

Any software executive will tell you that having customers, partners, and investors looking for ways to help you get your products to market faster is a great sign that you’ve done something right. At the risk of being overly bullish, I think AppsInHD represents the coolest thing to hit enterprise application software since SAP introduced a Windows front-end back in the early 1990s. [You may or may not believe me, but you can check it out here, or contact me and learn first hand what I'm talking about.] However, the paper isn’t about our marketing strategy, it’s about changing the way we build stuff so we can go faster.

The Go Faster plan isn’t a one page blog – its a comprehensive plan that looks at lots of initiatives that can help us deliver our software faster. It’s not a development methodology like Agile or Extreme either – there are plenty of those around, and we (like most everybody) use our own blend of the best elements of many formal methodologies. It is based on leveraging the underlying architecture of AppsInHD – which is fundamentally a mashup of enterprise web services – to create more functionality without more code.

The bottom line: the ‘Go Faster’ plan relies on a few key elements:
– Creating applications as a mashup of enterprise web services, leveraging the power of web technology to achieve scale and performance objectives.
– Working with web services that are application agnostic – that require no code changes when new applications are delivered – to improve reliability and speed core enhancements to all applications simultaneously.
– Working with an Application Browser – a user experience which manages all applications consistently, and which does not know what application is being used until the application tells it.
– Focusing application design, testing, and documentation on the trifecta of information flows: Entities – information resources that track information, Actions – information transformations that can be initiated for an Entity, and Use Cases – specific examples of Actions working against Entities to solve business problems.

With the foundation in place from delivering the first application, our development team can transform designs into reliable enterprise applications with blazing speed. Consequently, the Go Faster plan focuses almost entirely on the design process, and on re-thinking how enterprise Entities relate to one another and what Actions they must support in order to deliver the functionality required.

In my next post, we’ll look at the design strategies that emerged from the Go Faster plan in more detail, and show how application agnostic web services can make application design more efficient and more effective.

Posted in AppsInHD, Cloud computing, PHP | Leave a comment

Mashup Enterprise Services

Nostalgic for a late 60s console entertainment center complete with an integrated turntable, tube amp, radio, TV, and stereo speakers? Consoles were big pieces of furniture, the focal point of the room on which we would watch shows or listen to tunes. Over time we shifted our watching and listening from over the air and vinyl to cassette tape deck, CD player, VCR, cable, DVD, Blu Ray, HD TV, Flat Screen TV, Internet / wifi. To continue using the console with all these new devices, we could hire an electrical engineer (helped by a carpenter) and integrate each new piece. Updating an integrated system was too technical and too expensive, the consoles disappeared from our homes. We purchased component stereos and plugged in or replaced technologies as they became available.

The technologies in a modern entertainment center are loosely coupled components. Components may be added or removed by plugging them in (or using bluetooth wireless), no fuss or engineering required. This is similar to the way web pages are built in HTML. It is easy to add a weather applet to a page. Many designers combine applets on a web page to create a mashup – something completely new out of existing pieces.

It is time to take a mashup approach to ERP systems. A modern ERP architecture based on enterprise services can make it happen. The use of mashups in the user interface is common for HTML based applications. What is new is the architecture behind the API where the ERP transactions take place. This is where the enterprise services live. Traditional ERP systems integrate services within code, much like the console stereo. A vast ecosystem of system integrators get various pieces of integrated technologies to work with each other in order for the ERP to do its job. A modern ERP system should use loosely coupled enterprise services – getting pieces to work in new and interesting ways using a mashup process with little engineering required.

What does a mashup behind the API look like? Behind the API is a collection of independent services that operate like mini web sites. A mashup allows a request to carry just enough information through the network of services to respond to the request. Each enterprise service knows what it can do with the things of the enterprise application (employees, sales orders, paychecks, items), based on available metadata. Each service is integrated with the other services through commodity HTTP requests using REST – a protocol centered on management of information about things. The things provide the integration between services using ‘loose coupling.’ Additional services can be connected quickly and easily as needed, just like adding the weather to your home page.

Loose coupling is the answer in a rapidly changing world. In home entertainment the shows and tunes are the data, the components are the services that can be plugged in or discarded as needed. Old ERP systems are integrated systems like the console entertainment center. Modern Application Architecture takes advantage of loose coupling like the component stereo to keep your ERP competitive.

Posted in Cloud computing, PHP, Uncategorized | Tagged | Leave a comment

New Release Adoption Rates The Key Metric in Software

Getting the installed base to upgrade is becoming a survival imperative, as customers left on older versions compare what they have to what’s available from the cloud and find it wanting.

The ERP industry is finally taking the new release adoption rate seriously. This is attributed to pressure from cloud based competition and a too long product enhancement cycle compared to the cloud. The author claims cloud enhancement is continuous while on premises ERP follows a 3 year cycle. The key to retaining customers is not merely delivering value to them, but getting the customers to use the value of the enhancements to improve their operations. If the customer is not aware of or does not adopt new releases and features, the will find a vendor that delivers value to them. Losses in the customer base are fatal to software vendors, recurring maintenance revenues drive profits.

This is not news at HarrisData – we identified the adoption challenge 20 years ago. By 2000 we achieved an 80% new release adoption rate and have maintained new release adoption at or above that level since. It is not a trivial challenge. Customers must have incentives (usually improved functions and new technologies) that outweigh the costs and potential turmoil of an ERP upgrade. The incentives are easy, software companies routinely enhance products (a 15 month cycle here) and can tune enhancements to maximize value for customers by simply listening to the customers instead of being distracted by analysts. However an ERP firm’s customer care efforts should not stop at the CRM boundary. The bigger and more permanent actions must address the costs of an upgrade. This is more an engineering than marketing challenge.

The marketing parts are easy to understand, yet require backbone to put in place. At HarrisData we developed our Omni-License with the idea of new release adoption foremost in our minds. The Omni-License combines the initial license fee and five years of maintenance in one package. This makes it easier to for customers to obtain a long term lease and moderate payments when acquiring our ERP products. More is included. [This is the marketing part of the solution – there is always more. --ed] Source code, fixes, help line, and new releases are all included in the Omni-License. Source code gives the customer independence from the ERP vendor in customizing the product. Competition for these implementation services lowers the costs. The services vendor selected is licensed to a development copy of the product, has access to source code, and as the customer’s agent has access to the help line – all at no additional fee. HarrisData uses this access to help the customer and services vendor complete implementation tasks on time and on budget. The lack of fees allows us to be an honest broker between them, as well as to focus on the big picture and live date. New customers will have the opportunity to upgrade to new releases a couple times during the initial 5 years of the Omni-License. We work with the customer and their service vendor to ensure success in these upgrades.

HarrisData achieves an 80% new release adoption rate annually since 2000.

Even more is included. [surprised? –ed] This is the part that requires backbone. At the end of the 5 year Omni-License period, the customer has the option to extend the license or to convert to an AS IS basis (with no fee). We believe that over five years we will demonstrate to the customer that HarrisData continues to deliver increased business benefits that far outweigh related costs. We believe this so strongly we bet our profits on it. Our customers agree and opt to extend.

HarrisData achieves over 95% maintenance renewal annually since 1995.

When an ERP company bases profit on the success of each customer, the changes go much deeper than marketing. Customer Care efforts become a driver for customer success instead of billing. The support people focus on customer value received. The User Conference and the Lunch and Learn webinars focus on helping customers improve their use of the ERP software. Outbound support calls proactively look for ways to help customers, frequently ending in one or two hour mini training sessions on functions or processes important to the customer. The CRM incident handling functions provide insight into areas where customers struggle with implementations, upgrades, or even daily use of the ERP. What we learn from the Customer Care programs feeds the product enhancement process.

Many software companies use vendor comparison spreadsheets to prioritize enhancements. The idea is to check as many feature boxes as possible. At HarrisData the priority goes to enhancements which provide the greatest total value to our customer base. The list of functions missing or needing improvement come from the CRM along with estimates of the value of the enhancement and customer cost of modifying current function to fill the gap. The CRM also provides a count of how many customers would benefit from each enhancement. Enhancements with the greatest total value to customers get the highest priorities. High priority enhancements might include structural changes to lower the cost of creating and upgrading modifications as well as new and improved features. Our goal is to lower the amount customers spend on technical services to operate and upgrade the ERP. Over 20 years we made substantial progress in reducing service costs.

HarrisData receives 95% of its revenues from licenses and maintenance since 2000.

An ERP industry focus on new release adoption rates is long overdue. Achieving high adoption rates requires substantial rethinking of software company operations and enhancement priorities. The end result is stronger profits for ERP vendors, better ERP software in the marketplace, and much greater value realized by customers of ERP software.

Posted in Software Support, Uncategorized | Comments Off

The Web of Nouns

Web of Things is all the rage, where your smart phone starts your car and schedules servicing, or the refrigerator reminds you to pick up milk on the way home. In the near future things will connect to the web in vast numbers, many times greater than the number of people on Earth.

Consider your networked printer as an example. The printer is a familiar thing that is already connected to the network. When you decide to print your boarding pass or an invoice you send a file to the printer’s IP address. The printer prints the file. It will print as many files as you send to it. It also alerts you when it is out of sorts (low ink, out of paper). You can address or ignore the alerts when and as you choose, the printer will print your file when it is able to.

What happens when you take action to print your file? Verbs are the type of word that imply action. Yet when you look at what is passing through the network you do not see any verbs, you see a bunch of nouns. The print file is a noun together with the definition of that noun; the text, images, and fonts that define how the printed pages should appear. The alerts are nouns, with their definitions as printer features (paper, ink) and current status. The nouns travel between your IP address and the printer’s IP address. Nouns are the only things communicated. Nouns are not actions, yet your file was printed. What happened to the verbs? The printer itself is the verb. You provide a noun by sending the print file to the printer queue. The printer checks the queue and acts, it is the verb print. Nothing happens until you complete a sentence by linking a noun (the print file) to the verb (the printer).

Thus nouns connect the Web of Things. Like the printer, each thing connected to the web has a queue at its IP address plus the ability to send alerts to your IP address. From your phone you could send a show (channel, start & stop time) to a DVR, it will record that show. In the factory, one sensor counts units produced while another sends an alert if material runs out or a quality measurement drifts from specifications. In every instance the thing is a verb: record, count, measure. People complete sentences by linking nouns to the verbs of their choice.

Nouns perform the same role on the software side of the web. Modern Transaction Architecture is all about nouns, the various robots are the verbs, and people control it all by linking them. This is a big change from traditional transaction architectures which communicate via predefined verbs. Service Oriented Architecture is one example of a verb based architecture. In verb based architectures all noun-verb links must be predefined and preprogrammed. A big drawback is that each new thing must be engineered to participate in the transaction system – at substantial costs in integration and overhead for each individual communication in each direction. In the modern noun based architectures connections are linked and then mapped, not engineered. This greatly reduces integration costs and overhead. Transaction processing becomes as simple as clicking on links, bookmarking links for easy access, and searching links to find the best one to use.

Posted in Cloud computing, PHP, Uncategorized | Tagged , | Comments Off

A Modern Transaction Architecture

Consider the Payroll application as typically designed. The object is to convert hours worked into paychecks while calculating taxes, benefit deductions, and garnishments. The work flow is broken into a series of segments: hours entry, payroll calculations, verification, check printing. Each step is performed for the entire payroll as a batch and must be performed in sequence. If at the end one employee’s hours are in error, the entire payroll must restart the workflow and complete it in sequence. Provision is made to calculate a single paycheck, but only by exception. Throughout the process, the user interface constrains the user to this single work flow in a manner the payroll programs require.

Now consider modern Payroll application design. Hours load automatically (from time clocks or spreadsheets – it doesn’t matter), and the payroll checks are produced behind the scenes. The user is notified that hours are available, and alerted to problems with individual checks. The user corrects the problems where they occur and recalculates individual employee checks as needed. By comparison to past payrolls the user confirms that no undetected problems remain. The user interface in this modern work flow provides control to the user, who is no longer constrained by the technical requirements of batch processing. The result is accurate payroll with less user effort.

Roy Fielding proposed a modern approach to application architecture that complements this modern work flow—HATEOAS using RESTful services.

HATEOAS, an abbreviation for Hypermedia as the Engine of Application State, is a constraint of the REST application architecture that distinguishes it from most other network application architectures. The principle is that a client interacts with a network application entirely through hypermedia provided dynamically by application servers. A REST client needs no prior knowledge about how to interact with any particular application or server beyond a generic understanding of hypermedia. In a service-oriented architecture (SOA), clients and servers interact through a fixed interface shared through documentation or an interface description language (IDL).

The challenge is to unpack that definition (with apologies to Roy Fielding for any mistranslations) and relate it to creating paychecks (or other day to day tasks of a modern ERP).

A key feature is that it is not constrained by what happened before or what is to happen next, it is stateless. The implication is that the user can work at any point in the work flow, in any order they choose free of a sequence imposed by the server application. The user can calculate pay before loading vacation and sick hours, it is up to the server application to alert the user that some checks may need recalculation after the missing hours are added.

All interaction is through hypermedia, a link plus XML containing any needed data elements and metadata (the description of data elements). The user (via the user interface) sends a link and associated XML to the server. The XML contains the full knowledge of what the user is asking the application to do: search, update, query, etc. The application server returns XML as a response. This XML contains the search results, alerts, lists plus metadata (to tell the user interface how to handle the response). The metadata also includes the links for further action by the user. This provides the ability for a user to search for an employee, then click on a link in the search results to view vacation taken, approve or reject vacation hours requested for this payroll, and adjust this paycheck as needed.

The links are the key to modern applications. Links provide a stateless communication, with context in the XML, that allow the server application to perform work at the user’s request. The structure of acceptable links is known as the API. The API defines links which are complete, self-contained communications. The user interface (or client) requests and receives links in the same way an internet browser does. The browser doesn’t know one bookmarked link leads to a shopping site and another to movies, it simply lets the user click on a link and allows the response to instruct it in what to do. To a browser, an API is simply a set of potential links a user may click on. On the other side, the application server receives and responds to links the way a web server does. The API describes the path to the application server and the types of links it is prepared to respond to. As with a web server, this works beyond the walls of the application. Any authorized application may utilize the API to accomplish work. For example, an insurance provider may link to query whether any new dependents should be added to enrolled employees in their own system.

The application server itself can be anything, no one will ever see it since the API is what the world sees. This means that a legacy application can sit behind the API as easily as a shiny new one, provided the legacy application is not too dependent on controlling the work flow to operate. This allows developers to create the HATEOAS API with minimal reprogramming of existing applications, then modernize the applications over time with minimal disruption to users.

At HarrisData we found the modern HATEOAS approach delivers excellent results. In the process of upgrading our Payroll application product we upgraded the application technology in parallel. We created a combination of API, HTML5 touch / speak application browser, and an ensemble of application servers to support typical activities such as search, query, transaction, import, metadata / security, work flow escalation, and reporting. The API combines links with metadata to describe all activities in the application. The application browser navigates links and interprets response metadata into displayed information and new links. Each specialty server handles a particular type of task as fed by the API, accessing files as directed by the metadata. This technology does not depend on payroll calculations or the file structure. It is available to support the full range of ERP and CRM applications we provide – or any extensions or supporting applications created by our customers. The applications do not need to be rewritten from their legacy form, it is enough to simply call them from the specialty servers supported by application specific metadata. Rewriting is only necessary when new requirements obsolete the legacy code.

Posted in Cloud computing | Tagged , | Comments Off

What is Modern?

Rumors have SAP joining the stampede to HTML5 based user interfaces. To get there, SAP will build a new platform, replacing the $4 billion platform underneath Business-By-Design. HTML5 is the current technology for a “modern” user interface, filling the role Windows GUI and Java Applets played in the past. When the next user interface technologies arise HTML5 too will fade into the legacy technology graveyard.

Hopefully modern means more than the user interface technology of the moment. At HarrisData we believe modern means something other than the technology under the covers. [ed. We are delivering HTML5, CSS, JavaScript frameworks over a REST based API, but that is for another post]. We believe a modern system enables an age of robots, where most business transactions are executed through robot to robot processes monitored and controlled by knowledge workers. The first criteria of a modern system enables the productivity and ease of use introduced by the consumerization of business technology via smart phones and tablets. This provides people with control over the robots, using knowledge to keep data flowing throughout the organization. The second criteria take advantage of flexibility and ease of interconnection created by and needed for the cloud, web storefronts, and supply or demand chains. In most cases, these applications are computer to computer and do not have a user interface per se. The range of information requested / provided is similar to what a human clerk would need. We expect that robots will take over most data entry, calculation, and distribution. The full capability of the modern application does not require or depend upon the user interface technology, it is meant for robots with human oversight.

The human element in a modern system benefits from the consumerization trend of smart phones and tablets. Consider the tablet based shopping experience. Not long ago a consumer would find a part number in a paper catalog, call the order desk and dictate the order or mail the order form to an order clerk for entry processing. Later on the consumer may call the order desk to ask when the order might arrive. Today a consumer browses an online catalog and clicks on items to fill the shopping cart, then clicks to checkout. No data is typed in by the consumer, although item quantities may be adjusted or alternate shipping addresses added on an exception basis. The web storefront sends the order to the fulfillment system and relays order and shipping status for the consumer to browse at their leisure. Most of the action is robot to robot behind the scenes, with the consumer able to track, respond to notices, and adjust as needed. This is a profound change in the process, with various data clerks replaced by robots. The role of the user interface is to provide process control, not the traditional data entry of old style applications.

The modern user interface must perform tasks as consumers do. Clerical tasks (data entry, edit, load) will be performed by robots unless on an exception basis, so are a minor concern for the user interface. Control tasks are the focus. When controlling the robots, simple actions combined with feedback of robot activity provide instant gratification to the knowledge worker. Standard consumer activities such as bookmark, link, search, schedule, notify, and fix on the fly enable control. Add work flow to allow knowledge workers with greater understanding or authority to perform their part in the process. Let the robots perform the repetitive tasks behind the scenes, with activity counters and alerts to ease monitoring. Customizable content (change display fields without programming) allows knowledge workers to fine tune the controls and reduce clutter. Provide drill down capabilities for knowledge workers to investigate problems causing alerts. Include all robot to robot activity in audit trails to ensure processes operate properly.

The bulk of traditional work becomes robot to robot in a modern application. This requires a separate interface – the API – to enable automated processes. The API must include all the capabilities of the application from entry and edit to query and search (the API supports the user interface(s) too). The web storefront needs to be able to query order status, edit order details, and search for all the consumer’s orders. In order to interconnect with other robots, the API needs to support multiple standards such as JSON, SOAP, or even spreadsheets. The web storefront and a big box retail supply chain system may use different technologies, the application needs to support both sales channels. Entity and transaction import processes allow external robots to feed into the application, with knowledge worker notification and control. The web storefront or CRM need to feed the application new customer information as well as order transactions. Strong security protocols along with data encryption must be implemented behind the API so that access and activities are limited to authorized robots and tasks. This structure allows the modern application to participate in the cloud – even if it is located on your premises.

The modern application provides a very different world. No longer is the focus on data entry and validating user input — information is being sent electronically from one system to another. Applications help the users monitor and control information as it flows thought the organization. Users have the opportunity to spend more time understanding (and improving) business processes – becoming knowledge workers.

Posted in Cloud computing, Uncategorized | Tagged , , | Comments Off

Bookmark, Link, Search

[Highlights of CEO Keynote at HarrisData’s 2013 User Conference.]

Step away from the vendor hype wars over cloud computing and look at what the cloud means to users. Anything a user wants to do will be reached by a bookmark, a link on a page, or a search. The user does not care where the result comes from, just that it is easy to get to. Any claim to cloud computing must pass this simple user test.

Much of the argument over the cloud is based on technical and financial factors that are invisible to the user. Vendors argue without end that a multi-tenant architecture or virtualized server farm or what have you defines the cloud. Let’s refer to all these variations as robots (it is the 21st Century) — and how you acquire your robot is less important than what your robot can do. Acquiring robots is like acquiring cars. You can buy, lease, or rent a car and even ride in someone else’s car. Robots can be bought (private cloud), leased or rented (public cloud) or even shared (mash-ups). The choice has more to do with the robot acquirer’s particular needs and cash flows than the robot itself. The same robot could be acquired through any of these means.

More important than the means of acquiring a robot is whether the robot is able to work along with other robots in the cloud. Web Services is the language of robots in the cloud. Robots who speak Web Services more easily integrate with E-Commerce Marketplace robots or Social Media robots from elsewhere in the cloud to provide users with a rich experience at lower costs to the robot acquirer. This is true when providing inventory availability from your enterprise robot to the e-market robot behind the scenes as well as when providing shipping status from a logistics robot as a mash-up on your customer service robot page. Web Services accomplish the same integration as older methods, but with simpler, faster, and lower cost set-up.

Once you have acquired Web Services speaking robots, your users will reach the robots through their own smart phones and tablets. This Bring Your Own Device (BYOD) trend has grown from the days a person with their name on the building brought their Blackberry or Palm Treo to work and wanted it tied into the enterprise systems. Now everyone has one. The problem is the BYOD “one” is a consumer device, purchased by a consumer, and completely outside your control. Many brands and technologies are available, expect to see at least one example of each to show up and need to access your enterprise robot. How can you prepare your robot to allow all of them bookmark, link and search your enterprise robot from such an uncontrolled menagerie?

You could design, write, and test an App for each device – given unlimited time and budget! Fortunately there is a better way. Standards like HTML5 and CSS3 give you the ability to create touch and speak style interfaces that run across all BYOD devices. The standards allow you to keep data securely on within your robot while giving the user the full experience of their personal device. Given the high rate consumer devices are stolen or misplaced, this is a key consideration for enterprises. You don’t want your customer list or product formulas walking away with the device, and losing personal information such as social security numbers, bank account routings, or health care info in bulk is a massive headache. As a bonus, you only have to build the UI once!

HarrisData is upgrading the enterprise robots you use to allow bookmark, link, search within your enterprise. The first step was to construct a universal UI robot for “touch and speak” devices. Next we built a universal robot (actually a collection of robots) to manage a stateless conversation between the UI robot and the enterprise robots containing business logic like Payroll, Financials, Distribution, Manufacturing, and CRM. These robots use Web Services to speak amongst themselves as well as with special purpose robots created by our partners for retrieving tax rates or processing credit cards. Since these new HarrisData robots are universal, you can add your own business logic robots and give users appropriate access to your entire enterprise when they BYOD.

Today, the HarrisData Payroll for bookmark, link, search is in beta. It will be available to you via public or private cloud soon. We are working to connect the remaining business logic to the bookmark, link, search platform and look forward to providing you the results.

Posted in Cloud computing | Tagged , , | Comments Off

Too Big to Succeed

Cyprus is in the news as the world wrestles with insolvent banks in that country. The challenge is that a failure of the Cypriot banks would lead to wider failures across the world. The underlying idea is that banks can be too big to fail. The failure of one large bank takes all its investors, bond holders, and depositors down the drain with it, and if this group is large enough it could collapse entire economies. As governments fall with economies, governments declare banks “too big to fail” and find a way to bail out these banks.

So far no government has declared a technology company “too big to fail”, and these tech giants do fail as innovation and competition change the technology landscape. Many tech giants are in the news as they face the latest shift to touch screens, cloud, and big data. Should these firms be declared “too big to fail”, or are they simply too big to succeed?

A core competence is the result of a specific set of skills or production techniques that deliver value to the customer. Such competences enable an organization to access a wide variety of markets. Executives should estimate the future challenges and opportunities of the business in order to stay on top of the game in varying situations. -wiki

The key question: when is giant size helpful in technology? A standard way of answering this question is to identify the core competencies of a firm, and testing whether the firm’s activities focus on the competencies. The standard alternatives to focus are vertical integration or a conglomerate of unrelated parts. A firm which focuses on core competencies will succeed, others will not.

Apple has always been unique among technology firms, choosing to build both hardware and software of its own while “Wintel” took a commanding market share. For much of its existence Apple fit the idea that a preference for vertical integration rather than focus on core competencies leads to weak performance. The stunning move into portable music players – the iPods — certainly changed results for Apple. Vertical integration was retained with this new product, Apple still controls both hardware and software. How did Apple succeed with such a new and unrelated focus on music? Perhaps because for Apple a focus on music was not unrelated to its core competency . Apple long held market share for students and artistic computer users, its college student customers wanted a better way to collect, share, and bring music with them (Napster anyone?). Apple used its competency with these consumers to change the user experience and redefine technology at the point of use. Expansion of the music player to include games and other Apps, touch screens, cameras, phones followed by increased device sizes of tablet computers – iPads – follow a focused core competency in consumer computing.

HP provides a counterexample. Known for printers and servers (including consolidation of DEC and Compaq), HP decided to vertically integrate to capture a bigger share of corporate IT spending. Moving first to consulting (EDS acquired) then to networks (3Com), tablets (Palm) and lately to software (Autonomy) HP has yet to find a way to succeed as a whole. HP is a giant, and it wants to get bigger like IBM, but without identifying core competencies it will remain a conglomerate that is too big to succeed.

Amazon provides an example of growth through focus. Started as an electronic bookseller it has leveraged its core competencies in electronic retailing and order fulfillment to expand to all retail products. Amazon goes further by hosting operations and electronic stores for other retailers. Even its foray into tablet hardware – Kindle — and e-books center on the core competency.

Oracle dominated in databases then vertically integrated into applications. Acquisitions drive growth and substitute for innovation culminating in Oracle’s entry into hardware (Sun acquisition). Meanwhile customers move on with Hadoop and NoSQL instead of Oracle’s core database products. The mighty Oracle sales engine is faltering as distractions replace the “value to the customer” component of core competencies. Can Ellison regain focus or will Oracle acquire itself into too big to succeed?

In a world where the giants lose their way, what is a smaller tech firm to do? Get very familiar with your core competencies and focus your strategic moves in those areas. Your customers define the value of your competencies. If you are vigilant your customers may lead you to unexpected value as Apple moving into music. They will certainly lead you to consistent value as at Amazon in all things retail. Chasing size for its own sake may separate you from your customers as at HP and Oracle – then you risk becoming too big to succeed.

Posted in Uncategorized | Comments Off

Implementation Risk

Another day, another ERP vendor sued over an implementation failure. The customer did not achieve success implementing core ERP software and naturally blamed the vendor for inadequate support. You would think that by now someone somewhere would understand what it takes to successfully implement ERP software – and you would be correct. Success depends upon the executive management of the organization implementing an ERP system for its own use. Only the executives can decide which features are priority number one for an implementation. Only the executives can say no to users who wish to alter commercial ERP systems rather than alter their personal workflows to take advantage of purchased software. Only executives can monitor the implementation process to see that it is on time and on budget. (The implementation process and executive responsibilities are detailed in HarrisData’s Quick Start Implementation Guide). Unfortunately, some executives would rather shift blame than do their jobs.

That said, no vendor should hide behind this executive responsibility instead of doing their part in assisting a customer organization’s implementation process succeed. In this instance, the vendor faced several self-imposed challenges which may have inhibited their ability to assist the customer. The ERP software was sold through a distributor, putting an intermediary between the vendor and direct communication with the customer’s executives. The ERP vendor was acquired by a larger consolidator, requiring new relationships between the vendor, the distributor, and the customer. The vendor’s project team assigned to the customer implementation left the vendor (this is attributed to the acquisition, but occasionally happens anyway). It is the vendor’s responsibility to support the customer through these day to day challenges (although the vendor in question may focus acquisitions more on big footprint / cost reduction than improved support / organic growth of acquired products). The vendor did not do so to the customer’s satisfaction.

Frank Scavo focuses on concrete things a customer organization can do to minimize these type of implementation risk. They are an excellent set of recommendations. HarrisData makes it easy for our customers to take the recommended steps by implementing our Software Customer Bill of Rights in our OmniLicense for ERP software. We also try to maintain contact with customer executives throughout the implementation to remind them of their responsibilities and options, and to make sure HarrisData lives up to our commitments. However , success depends upon the customer executives and is their accomplishment when achieved.

Posted in Software Support | Tagged | Comments Off