You are currently browsing the category archive for the ‘Supply Chain Performance’ category.
Teradata continues to expand its information management and analytics technology for big data to meet growing demand. My analysis last year discussed Teradata’s approach to big data in the context of its distributed computing and data architecture. I recently got an update on the company’s strategy and products at the annual Teradata analyst summit. Our big data analytics research finds that a broad approach to big data is wise: Three-quarters of organizations want analytics to access data from all sources and not just one specific to big data. This inclusive approach is what Teradata as designed its architectural and technological approach in managing the access, storage and use of data and analytics.
Teradata has advanced its data warehouse appliance and database technologies to unify in-memory and distributed computing with Hadoop, other databases and NoSQL in one architecture; this enables it to move to center stage of the big data market. Teradata Intelligent Memory provides optimal accessibility to data based on usage characteristics for DBAs, analysts and business users consuming data from Teradata’s Unified Data Architecture (UDA). Teradata also introduced QueryGrid technology, which virtualizes distributed access to and processing of data across many sources, including the Teradata range of appliances, Teradata Aster technology, Hadoop through its SQL-H, other databases including Oracle’s and data sources including the SAS, Perl, Python and even R languages. Teradata can provide push-down processing of getting data and analytics processed through parallel execution in its UDA including data from Hadoop. Teradata QueryGrid data virtualization layer can dynamically access data and compute analytics as needed making it versatile to meet a broadening scope of big data needs.
Teradata has embraced Hadoop through a strategic relationship with Hortonworks. Its commercial distribution, Teradata Open Distribution for Hadoop (TDH) 2.1, and originates from Hortonworks. It recently announced Teradata Portfolio for Hadoop 2, which has many components. There is also a new Teradata Appliance for Hadoop; this is its fourth-generation machine and includes previously integrated and configured software with the hardware and services. Teradata has embraced and integrated Hadoop into its UDA to ensure it is a unified part of its product portfolio that is essential as Hadoop is still maturing and is not ready to operate in a fully managed and scalable environment.
Teradata has enhanced its existing portfolio of workload-specific appliances. It includes the Integrated Big Data Platform 1700, which handles up to 234 petabytes, the Integrated Data Warehouses 2750 for up to 21 petabytes for scalable data warehousing and the 6750 for balanced active data warehousing. Each appliance is configured for enterprise-class needs, works in a multisystem environment and supports balancing and shifting of workloads with high availability and disaster recovery. They are available in a variety of ratios including disks, arrays and nodes, which makes them uniquely focused for enterprise use. The appliances run version 15 of the Teradata database with Teradata Intelligent Memory and interoperate through integrated workload management. In a virtual data warehouse the appliances can provide maximum compute power, capacity and concurrent user potential for heavy work such as connecting to Hadoop and Teradata Aster. UDA enables distributed management and operations of workload-specific platforms to use data assets efficiently. Teradata Unity now is more robust in moving and loading data, and Ecosystem Manager now supports monitoring of Aster and Hadoop systems across the entire range of data managed by Teradata.
Teradata is entering the market for legacy SAP applications with Teradata Analytics for SAP, which provides integration and data models across lines of business to use logical data from SAP applications more efficiently. Teradata acquired this product from a small company in last year; it uses an approach common among data integration technologies today and can make data readily available through new access points to SAP HANA. The product can help organizations that have not committed to SAP and its technology roadmap, which proposes using SAP HANA to streamline processing of data and analytics from business applications such as CRM and ERP. For others that are moving to SAP, Teradata Analytics for SAP can provide interim support for existing SAP applications.
Teradata continues expansion of its Aster Discovery Platform to process analytics for discovery and exploration and also advances visualization and interactivity with analytics, which could encroach on partners that provide advanced analytics capabilities like discovery and exploration. Organizations looking for analytic discovery tools should consider this technology overlap. Teradata provides a broad and integrated big data platform and architecture with advanced resource management to process data and analytics efficiently. In addition it provides archiving, auditing and compliance support for enterprises. It can support a range of data refining tasks including fast data landing and staging, lower workload concurrency, and multistructured and file-based data.
Teradata efforts are also supported in what I call a big data or data warehouse as a service and is called Teradata Cloud. Its approach is can operate across and be accessed from a multitenant environment where it makes its portfolio of Teradata, Aster and Hadoop available in what they call cloud compute units. This can be used in a variety of cloud computing approaches including public, private, hybrid and for backup and discovery needs. It has gained brand name customers like BevMo and Netflix who have been public references on their support of Teradata Cloud. Utilizing this cloud computing approach eliminates the need for placing Teradata appliances in the data center while providing maximum value from the technology. Teradata advancements in cloud computing comes at a perfect time where our information optimization research finds that a quarter of organizations now prefer a cloud computing approach with eight percent prefer it to be hosted by a supplier in a specific private cloud approach.
What makes Teradata’s direction unique is moving beyond its own appliances to embrace the enterprise architecture and existing data sources; this makes it more inclusive in access than other big data approaches like those from Hadoop providers and in-memory approaches that focus more on themselves than their customers’ actual needs. Data architectures have become more complex with Hadoop, in-memory, NoSQL and appliances all in the mix. Teradata has gathered this broad range of database technology into a unified approach while integrating its products directly with those of other vendors. This inclusive approach is timely as organizations are changing how they make information available, and our information optimization benchmark research finds improving operational efficiency (for 67%) and gaining a competitive advantage (63%) to be the top two reasons for doing that. Teradata’s approach to big data helps broaden data architectures, which will help organizations in the long run. If you have not considered Teradata and its UDA and new QueryGrid technologies for your enterprise architecture, I recommend looking at them.
CEO & Chief Research Officer
The keynote theme at this year’s Sapphire conference in Orlando was Simple. Top executives from SAP, a software company associated with complexity, stated and restated that its future direction is to simplify all aspects of its products and the ways customers interact with them and the company itself. SAP’s longstanding and commendable aspiration to thoroughness in its software will be giving way to an emphasis on elegance in its engineering. This objective is more than admirable – SAP’s future competitiveness depends on it. Changing the fundamental architecture of SAP’s offerings – already well under way with HANA – is absolutely necessary. The design underpinnings in SAP’s ERP applications, for example, have been shaped by technology limitations that have disappeared, as Dr. Hasso Plattner, one of the company’s founders, pointed out in his keynote. However, the relevant issue facing SAP and the software market is how far the company can progress toward this goal and how fast.
The stress on simplicity in the keynote addresses may have been more for internal consumption – a stake in the ground to mark an organization-wide turning point – than for the thousands of customers in attendance. This year’s Sapphire marks only the beginning of what will be a challenging but essential journey for the company.
ERP is a core business for SAP. It’s the product where simplicity is most needed but where it will be most difficult to achieve. The next generation of ERP – the core financials, manufacturing, operations and distribution – must enable line-of-business people to modify the system to adapt to changing business environments and modify business processes to reflect evolving internal requirements and adoption of new management methods. In our ERP research only 21 percent of larger companies said implementing new capabilities in ERP systems is easy or very easy while one-third characterized it as difficult. Because of this, the current generation of ERP software is a barrier to innovation and improvement. To be sure, the initial configuration of and major modifications to a new ERP system almost always require a mix of external consulting, internal IT and business people to achieve the best outcome. But even here software vendors must radically reduce the system’s setup cost. Today, the cost of implementation can be up to five times the cost of software license. In the future, companies must be able to do this at a fraction of the cost. Cloud-based systems are one way to achieve these kinds of savings, and the cloud was a hot topic at Sapphire.
There’s a debate on whether SAP is a cloud vendor. Some IT analysts see a dividing line between incumbent, on-premises vendors and the newer cloud-based ones. If a cloud vendor is one that only (or mainly) operates in a multitenant cloud environment, SAP is not one. But strict definitions of what qualifies as the cloud already have limited relevance to the market generally and to SAP’s business buyers. Moreover, the issue of which is a real cloud vendor will become increasingly less important to users of these systems over the next five years as software environments evolve to a hybrid cloud model that combines multitenant, single tenant and on-premises deployments.
I’ve discussed the business reasons why multitenant configurations have been the dominant architectural approach to software as a service (SaaS). Multitenant is inherently more economical than a single-tenant configuration. The savings that vendors have been able to pass along to customers have provided a compelling reason to acquire software in this format. This has been true for any software category that can be configured rather than customized. That is, the modifications necessary to make the software suitable to the specific needs of the user organization (configuration) can be kept separate from the core code. This is enables the vendor to update and modify the core software used by all of its customers at once without (in almost all cases) affecting the individual customer’s configurations. Sales force automation and travel and expense management software were two of the earliest multitenant categories to be widely adopted because they were designed to make it easy for users to configure the system in useful ways without touching the core code.
However, not every company has found that software in a multitenant environment serves its needs. This is especially the case for complex applications such as ERP, as I’ve noted. While cloud-based ERP has been a hot market, expanding rapidly over the past 10 years, a majority of ERP deployments remain on premises. Growth in the cloud segment has been driven by the superior economics for buyers that were able to accept the software’s limited configurability and by growing midsize companies that were able to migrate from entry-level accounting software sooner than was practical with on-premises software. The pace of adoption has been accelerating as companies have gotten comfortable with this method of deployment; plenty of organizations have found that this approach works for them, and security concerns have ebbed. Yet these multitenant cloud ERP offerings do not have all the functionality or configurability to address the requirements of a majority of the market. This is the biggest challenge – and greatest opportunity – in the ERP software market.
The root cause of the need to customize an ERP system is the forms-based table structure almost all them use. The first generations of all business computing systems were created as analogs to existing paper-based systems, similar to the way that the first automobiles were “horseless carriages” in their configuration. ERP systems also have mimicked the multiple ledger structure of paper-based accounting systems (which is pointless and even counterproductive in a computer-based system) and the paper-based forms that are the information containers used in accounting processes. In the first stages of business process automation, this simplistic automation was the only practical approach since it was the easiest way for programmers to start. But just as the design of cars evolved into a totally new form to reflect the capabilities of the underlying technologies, business computing systems have to evolve to break out of the shackles imposed by paper analog structures.
To break the configurability barrier ERP systems have to be more flexible in their basic design. Ideally, they should eliminate the need for customizing the underlying application. Companies would benefit if modifications are easier – and potentially less expensive – to make initially and to adjust as business conditions change over time. Easier configurability also can make it possible to reconfigure processes and capabilities faster and more cheaply than is possible today, enabling companies to make their ERP system more adaptable to their business needs. Separating the individual configurations from the core code base means that SaaS vendors can give a much broader set of users the flexibility they need to make the system work their way while still having only a single instance of a code base to modify, upgrade, debug and patch.
So the race is on to make multitenant ERP the appropriate choice for a significantly larger market. One approach that vendors can take to address this issue is to build in adaptations to the specific needs of a broad set of specific vertical or micro-vertical part of the core code. Another is to take a fresh approach to the design and architecture of ERP systems to make them inherently more configurable. Both changes could increase the number of companies for which a multitenant application suits their needs. But both are time-consuming and difficult to bring to market. In theory, a fresh approach is the more sustainable strategy, but it’s better suited to a startup than a huge company like SAP.
In the context of being able to offer an attractive ERP offering in the cloud, the question of whether SAP is a cloud vendor is still relevant because it gets to the heart of the simplicity issue that the company is attempting to address. For SAP to sustain its position in the market, its product must become far easier to implement and configure to the needs of an individual company regardless of how it’s deployed. The design requirement that SAP must meet is to have an ERP system with rich functionality that is as easy to deploy as those offered by cloud-only vendors but that can be readily customized to the specific needs of companies willing to bear the extra implementation and operating costs of a single-tenant or on-premises deployment.
SAP is already rolling out software with names that meet its simplicity theme, including Simple Finance. At first this exercise in branding seems both ridiculous and confusing. Ridiculous because, in reality, finance applications usable by midsize and larger companies will never be simple. Business and regulatory factors keep them from being so. Confusing because, for example, people may think the application is aimed at smaller midsize companies or is perhaps a retread of SAP’s ill-fated ByDesign. On the whole, though, “simple” is not a bad idea for branding if SAP demonstrates substance behind the trademark. The label also can be useful in focusing SAP developers on what the customer wants. SAP’s finance software will never be simple, but it must be as simple as possible.
Simple isn’t easy, especially when it involves moving a large organization in a new direction. Uniting SAP around the objective of “simple” is a good management strategy, but it will require consistent follow-through over the next months and years to make it a reality in the company’s products and processes. This is far from assured but by no means impossible. SAP’s user groups must hold senior management accountable for delivering results that demonstrate measurable progress toward simplification. Results in the software market will demonstrate the extent to which it is succeeding in meeting rising demand for ERP software that’s more flexible and adaptable and easier to deploy, maintain and update.
Robert Kugel – SVP Research