Over time, we have all heard software vendors, analysts, consultants, and media talk about architectures. They use terms like enterprise architecture, software architecture, service-oriented architecture (SOA), event-driven architecture (EDA), and enterprise services architectures.

Is IT like the art world, where there are movements and styles, with leaders who set radical new trends for others to follow? Or are all these architectures related to each other? Why is it all so confusing?

The chief reason for confusion is that IT people have been using the concept of architecture to describe two different things: architecture for the software itself and the architecture for the corporation. This is like confusing the architecture of buildings and urban planning for the design of cities.

Today, Infor announced Infor Flex, a new program that gives customers a clear, fast and cost effective path to adopt Infor's latest product innovations. Jim Schaper, Infor's Chairman and CEO, provides a short introduction to Infor Flex in this video. Below the video is an overview presentation. 

Infor Flex Overview Presentation

Here's a quick overview that gives more details on the program (click the projector icon to see it in full screen mode). You can also visit the website for more information. As always, your feedback is welcomed in the comment section.

Hi all,

Greetings from Las Vegas! We are having our annual Inforum conference and one of the big announcements, one that I am personally most proud of, is Infor MyDay.  Infor MyDay is a new Web 2.0 user interface for Infor applications, but since it’s based on Infor Open SOA it can pull information from virtually any application or data source.

But calling Infor MyDay a user interface is kind of an understatement because it’s much, much more. Infor MyDay is designed to deliver persona-based content to over 150 roles we have identified in our customers’ businesses.  The content is delivered through pre-defined metrics and reports.  And because it is based on our Web 2.0 technology, the content is intuitive and personalizable to the needs of any individual’s unique requirements.

On top of this, all of the content we deliver is actionable.  What does that mean?  It means that you can drill down into the source systems for further analysis or to enter transactions.  The result is that employees have a central location to find the information that they need in real time to make decisions and complete their work.

What do we mean by persona-based? A persona is a composite of a user within an organization. A lot of vendors talk about role-based interfaces. A persona takes this concept to the next level. A role is generic, designed for a departmental role such as the “finance user.” A persona is specific to an individual user within that department, such as the VP of Finance or Controller. A persona also adds texture to that individual. At Infor, we’ve given them names and faces and built stories around their life. These are imaginary people, but they are based on the hundreds of users we studied to understand the real needs that real people need to get their jobs done. From conception, design and development to sales education and marketing, this gives us the understanding we need to build and deliver great content for people.

Let’s take a look at one of the 16 persona roles we are delivering with this first release, Bob the Production Planner. Bob is a composite of the typical production planner.  He is the choreographer of the manufacturing shop floor, managing planning and production. He determines what to produce, how much and when it’s needed. He acts as the go-between between the shop floor and the corporate side of the firm. He has a degree, probably business or engineering, and about 10 years experience with manufacturing. He knows how to use applications but he’s not an IT gearhead.   

Bob has to deal with unexpected events – late purchase deliveries, machine downtime or last minute work orders. He wants to be more proactive, but the reality is that he is in ‘reacting mode’ much of the time and plans are always changing. He has to deal with inaccurate inventories and bill of materials, and he has an avalanche of unstructured information that he needs to gather, format and assimilate to take action on. 

From our research, we have learned Bob’s typical responsibilities, his skills, his working environment, pain points and goals. We have learned how he uses his ERP software, the other applications he uses and the value he needs to get from them. We learned all of this because we’ve done our homework. A lot of it. We started in early 2007, logging thousands of hours of research into the personas of the people using our software. We’ve built-in the content they need to make their lives a little easier, so they can focus on strategic activities instead of looking for information.

These in-depth personas allow us to deliver rich and targeted user experiences, making Infor MyDay unique to the market. I’ll be talking a lot more about Infor MyDay here in the future, because there’s a lot more coming down the pipe. So stay tuned!

Posted by Jeremy Suratt, Director, Technology Marketing

A common mistake when people talk about SOA is to lump it together with web services. Some people think that SOA is web services because they get lost in the discussion when acronyms like SOAP, UDDI and WSDL are thrown around. Let’s not even mention WS-AtomicTransaction, WS-BusinessActivity, WS-Policy, WS-ReliableMessaging… the list goes on.  In fact there are so many details around those standards that they have become known as WS-* for short. 

SOA is not about web services: SOA is about how to get to your application architecture on a level so that businesses can better adopt new functionality without disrupting existing investments.

A Little Background

Behind the curtains, part of SOA architecture is connectivity.  I like to define two types of style for the sake of simplicity: either you connect real-time (synchronous) or by events (asynchronous).

Let me give you examples of these in action. If you are buying your favorite MP3 player online and, at the moment of ordering, you receive the right price and the right availability then that is real-time. Once you click “order” and that order is processed an event occurs.  The event generates a message that the shipping department must respond to, but it doesn’t need to be in real time.  That order is then handed off to the shipping department and put into their work queue. 

As you have read from the previous posts, Infor Open SOA supports the event-driven style and enables solutions to remain independent of each other, which in turn promotes flexibility and scalability. Nevertheless there are cases, like the one I just described, where a real-time style is required.

Getting to the point…

Since the advent of SOA, the only technology that has been positioned for the real-time style is web services using (here it goes....) SOAP and WSDL.

• What’s SOAP? It is a technology to “envelope” the message you send or receive.
• What’s WSDL? It defines the structure of the message you send or receive.

Think about sending a letter to your friend: the envelope where you put the letter is SOAP while WSDL defines how the content of the letter inside is structured.

The current incarnation of web services has failed to deliver on the hype.  Although web services are widely used, there are too many variations on the standard. This makes it difficult to reuse services without adding additional development. 

So, is there an alternative?

Yes!  REST (Representational State Transfer) offers an alternative to build real-time connectivity in a much simpler way. Although the acronym may sound difficult, REST uses the World Wide Web style that everybody knows to access information. Instead to “enveloping” data and constructing difficult and complex data requests, REST leverages a URL to access data.

For example, if your company offers a catalog of MP3’s, the way you would access from a program is like you do in your browser: http://myco/catalog/mp3. If you would like to access a specific mp3 and its price, the link would be looking like: http://myco/mp3/price/modelXYZ. REST can return different formats like XML and HTML, just like the web does today.

Now I‘m not advocating that you throw out your web services development. As the American’s say, “if it ain’t broke, don’t fix it.”  However, in the future, there is a better option.  REST is simple and open to everybody, and that’s what made the WWW successful.  This is certainly a style to consider when you architect real-time type of connectivity. In a future blog, we will touch base how Infor Open SOA leverages REST in its architecture.

Posted by Massimo Capoccia, Director Product Management, Technology

If you call someone on the telephone today, you will almost always connect to the person you are trying to reach. The technology is so trustworthy that you no longer question whether or not you will be able to reach people on the other side of the world. However, if a person you call doesn’t speak the same language, communicating can still be a problem despite the technical advancement.

This is essentially what is happening in the IT world now:  vendors have invested in tooling to connect software systems, components and services with each other. Over the last few years, the development focus within SOA has been to find a standard way of connecting software systems and “enveloping” information.  These are some of the largest pain points for Enterprise Application Integration (EAI).

In order for exchanged information to be commonly understood, a shared business language and common concepts are necessary, and the software industry needs to come to grips with this fact. There have been improvements over the last few years, for example, in the field of Master Data Management (MDM). Unfortunately, it is often only tooling that is offered and not the business functionality to, for instance, manage the “lifecycle” of data. There is also a danger that companies will enforce their own MDM-standard definitions, which can mean a never-ending process and effort for expensive governance teams.

Not defining a standard for information exchange leads to time-consuming mapping (translation) to define the languages spoken between different systems. This is a crucial point where many IT projects fail, in regards to time and budget. The problem can be compared to the daily functioning of the European Parliament. Here each member speaks in his or her own language. Translators must relate each word in “real time” into the language of every other member. Result: inefficiency and sky-high costs (paid for by the European citizens).

The Open Applications Group (OAGi) is developing a standard for how business documents and concepts should be defined to solve this problem. The interesting thing here is that not just IT companies that are participating, but also trend-setting companies from various industries. Each has the same goal: to define the common business language for information exchange.

If you think back, EDI comes quickly to mind, especially the circumstances under which it failed to gain pervasive use. In contrast, there are many different reasons why OAGi has a real chance to succeed. First, it is both IT and non-IT industries’ perception that a common language is of utmost importance and would bring many advantages. Secondly, the technology has come a long way (think XML) and the communications infrastructure has become a commodity through the Internet. OAGi should not be seen as a B2B application, but as a solution to help define the information exchange inside company walls.

SOA needs a shared business language and MDM - that much is certain. However, SOA projects have difficulty adding value when only tooling and expensive governance teams are involved. Often this approach means time consuming discussions about how an address field must look. Organizations such as OAGi, which are doing the hard work of standardizing business information, offer a much needed solution to this problem. They are speeding the process of message definition, resulting in more efficiency and increasing the chance for “out-of-the-box” interoperability with other software systems. This will hasten the discovery of a shared language for SOA.

Imagine you could pick up your phone and call anywhere in the world and communicate seamlessly without any language barriers.  Organizations like OAGI are going to help us create a common language for business applications, improving customers’ ability to cost-effectively assemble the right software for their business.

Posted by Massimo Capoccia, Director Product Management, Technology

Part 5 of 5 in a series of posts focused on the Infor Product Strategy

Let’s look at a specific example of a component that we are creating that offers non-disruptive innovation: Multi-book General Ledger component that will be delivered in early 2009.

In talking to controllers and other financial professionals, we knew that M&A and globalization were huge pains for them. The ability to operate multiple ledgers at the same time would be a significant benefit for them, saving both time and money.

For instance, let’s assume you are a local operating organization acquired by a holding company. The best way for you to operate your business is to keep your own base general ledger, while the holding company maintains its own corporate general ledger. With Multi-book GL, we can allow them to enter one journal entry in their local general ledger, which is then populated in the separate holding company’s books.

If that same company operates in France or China those governments mandate that companies use specific general ledger chart of accounts (account codes), for reporting purposes. IFRS, used in many parts of the world, has the same requirement.

If there is a joint venture, companies must report separately, or if there is a business unit that may be planned for divestment, then the parent company will want to run a separate ledger for that business unit. Costing ledgers and projects must be maintained separately from the general ledger. So there are many reasons that companies need to maintain separate ledgers.

Multi-book GL allows the customer to maintain a local operating set of books, which can then be mirrored into a French version, a Chinese version, an IFRS version, or however many they may need. That means the customer can close their books faster, more accurately and without any spreadsheet manipulation at the end of every reporting period.

Multi-book GL can operate alongside an existing general ledger in the ERP system, it can run concurrently with it as a customer transitions, or it can become the primary general ledger that replaces all others. It can be taken on or off-line easily without disrupting the rest of the enterprise because it is loosely-coupled.

This is just one example of our component strategy and we will be delivering a number of others all based on the same basic principles. What they illustrate is the power of focusing our collective development efforts to deliver new innovations that minimize complexities, which the customer can implement without disruption.

Posted by Bruce Gordon, CTO

Part 4 of 5 in a series of posts focused on the Infor Product Strategy

Infor has identified six broad areas of concern that we call the “Six Pillars of the Networked Enterprise.” These pillars provide the framework that allows customer solutions to interoperate and collaborate in a heterogeneous world.

The term “Networked Enterprise” indicates the new realities that companies face in this era of globalization and coopetition.

• Companies are increasingly complex, with disparate business units and global subsidiaries
• Continued industry consolidation is forcing companies to bridge the different business platforms of their acquired companies
• More companies are collaborating with trading partners but must present a united front to the customer

Consider a networked enterprise that consists of different platforms at the plant, division, subsidiary levels or with the platforms of different partners.  When we externalize the 6 pillars, the resulting solutions can operate much more cost effectively in this heterogeneous environment. .

Think of it like this: in a house you have a standard inlet for electricity, water, gas, cable, and the other infrastructure required to run a household. These are exposed via standard outlets so that people can easily connect to the services offered by municipalities and businesses.

We need to accomplish the same thing with our IT systems today. With the 6 Pillars, Infor is externalizing and standardizing the key functions that customers need to operate in today’s business environment, bridging systems internally and externally with partners.

Here’s a quick overview of the Six Pillars:

• Information and Master Data Management (MDM) – The need to collect, manage and analyze information in order to make business decisions is fundamental to solutions architecture. MDM makes sure that we maintain one version of the truth, managing information across different applications and normalizing the data. All reporting, business intelligence and performance management tools connect to this pillar.

• Inventory and Resource Management – All industries run on selling or consuming inventory, which can consist of products or services. There needs to be visibility into and control over the inventory components that are needed to create products, their availability and location. When they are finished goods, companies need to be able to reserve them so that you can sell them to customers. This is also true in a services industry, where the company is selling services where you must reserve human talent or other equipment needed to deliver the service. For example, if you are a wholesale distributor and you are selling a product that require installation then you need to schedule the availability of the products and the technician that’s going to install them. You must also bear in mind that the products or services may be sold through a subcontractor, and you must have insight into their availability as well – which requires that they be externalized.

• Business Control – Business control is the glue between different business parties and their systems. Business control must be externalized in order to orchestrate processes within and across applications. This allows the customer to adapt their enterprise-wide business processes. Event management is required to ensure that you are meeting service level agreements. Event management is like the hall monitor that makes sure things are working properly and issues reports when they aren’t.

• Money – Every company must manage money and there needs to be a holistic view of the money and capital that is going into and out of the business. This requires that all accounts be externalized outside of the core ERP system.

• Assets – Companies need to know what assets they have, their current status and maintenance schedules. They need visibility across the networked enterprise to make sure that assets are available when they need them. For example, if you shift manufacturing from one plant to another, you need to make sure there is no downtime. For this reason, assets must be externalized and available to different systems.

• People – businesses run on people and this requires time and attendance, scheduling, as well as compliance and regulatory needs.  Why are people externalized from your core systems?  People resources can be yours or your trading partner’s.  You need to have visibility and control across these different companies.  Let’s take a look at an example.  A global manufacturer may decide to partially outsource its field service department in order to reach all of their customers.  When scheduling service visits, this company needs to schedule and reserve inventory and field service engineers.  By externalizing People, you get better visibility and management of these resources, regardless of who they belong to.      

By having these six pillars externalized, it allows our developers to solve new business problems for the customer, which can work with multiple systems within their extended enterprise as well across their network of business partners.

These 6 pillars allow us to build components in a much more loosely coupled way and externalized from the existing core application. For example, a customer could be running a mainframe ERP in one location, an IBM System i ERP in a different division, and a have business partner running a Microsoft or Linux-based system in another. A loosely coupled Inventory Control component can send and receive data from the disparate ERP systems and avoid the integration difficulties and complexities that are inherent to built-in ERP modules.

OK.  We understand that these 6 Pillars may seem a little abstract. So in our next post we will go over a specific example to help us understand how it works to address real world business problems.

Posted by Bruce Gordon, CTO

Part 3 of 5 in a series of posts focused on the Infor Product Strategy

In the last post, we talked about the complexities of adding features to a core ERP, using a dice analogy. As you add features in this way, it exponentially increases complexity.

As Infor adds new functionality, we can reduce the complexity by externalizing functionality into separate autonomous pieces.

We’re doing it through a component-based strategy.  That means software components, built on modern technologies, which are delivered in a SOA-based framework. We are moving in this direction to solve the complexity problem, but also because this is how customers want their software.

What I mean by this is that no customer has ever come to me and said, “I want you to improve the core kernel of our ERP system.” They come to us to add functionality to specific modules. For instance, the controller asks for improvements to the general ledger or the VP of sales wants more flexibility for different types of pricing in the pricing module.

Unfortunately, as I discussed in previous posts, ERP system modules are so tightly coupled that it’s difficult to upgrade one module without impacting the whole system. That creates business disruption that we must avoid. 

The solution is software components. While the difference between a module and a component may seem like wordplay, they are fundamentally different.

A module is tightly coupled at the business process and database layers, essentially part of the core application. It’s separate only in the sense that the vendor licenses it separately but it’s still part of the core ERP. You can’t mix and match modules.

A component is self-contained and autonomous, but can be attached to an ERP system or other solutions to extend or upgrade or create a new business process.  The component architecture is based on SOA, which provides the loosely-coupled interoperability and ultimately delivers the flexibility to independently manage and upgrade your systems in a way that hard-coded modules can’t approach.

We’ll refer to how this entire environment interoperates and coexists in a later post. SOA now allows us to operate in a distributed framework, eliminating the interdependencies and complexities that arise from putting all our eggs in one ERP basket, but still maintain that holistic view and business control. One of the advantages of the component approach is that, because they are autonomous, they can be leveraged across multiple business-specific ERP platforms. Some people have pointed out that this is an advantage for Infor, a way to rationalize development for our multiple ERP systems. 

They are exactly right – but that’s not the whole story.

It’s a tremendous advantage for our customers as well, who want value for maintenance, which they will get it when we can focus all the resources of global development teams into specific software components that are designed to benefit our entire product portfolio as well as those of other vendors. It’s inherently open.

These components will have the best intellectual property from across our product lines built-in. For instance, we can take the pricing expertise from across our entire global development team and build the best pricing component available – and one which all of our new and existing customers can use. Customers will benefit from a hugely expanded list of business-specific features or simply turn off the ones they don’t need or that aren’t relevant.

Next week, we’ll talk about how we are focusing in on the components to develop, through what we call the “Six Pillars of an Enterprise.”

Posted by Bruce Gordon, CTO

What do a cell phone, cable TV box, car entertainment system, application server, integrated development environment (IDE) and enterprise application all have in common?  Well, from a software standpoint, many of these devices and applications are now written in Java. But that’s not the only thing they have in common. More and more of these devices now run their software under the control of a technology called OSGi.

OSGi, short for Open Services Gateway initiative, is a Java container specification designed to be the standard for the embedded internet-connected home appliance market. There are now several implementations of the specification available, including two that are open source, Apache Foundation Felix and the Eclipse Foundation Equinox. In fact, if you are a software developer, you might be using OSGi in your integrated development environment (IDE). The Equinox OSGi container provides the technology behind the handy plug-in functionality in the Eclipse IDE.

So why do enterprise application developers care about OSGi?  Modern application architectures often market their interoperability and ability to just plug-and-play with other applications at run-time.  The reality is that there are a lot of dependencies and complexities to make this work.  Look under the covers:  How do you handle multiple component versions? Supported configurations? How do you manage these components independent of each other without disruptions? 

Now I wouldn’t say that OSGi is the magic bullet that solves all of your problems.  But it does provide a standard framework that allows developers to design and write software as “Lego” block’s that can be plugged together at run-time allowing the addition of new code without having to rebuild, redeploy or otherwise touch any existing code. 

Here are some of the key benefits of using OSGi for Enterprise Application development

• OSGi allows multiple applications to run in one environment without disrupting each other.  This means that different components can be deployed into the same environment.  Those components can take advantage of the same underlying component, or if need to be, a different version of the same component.  The OSGi container also manages dependencies of all components, including versioning.
• Code can be deployed to an environment in-line without requiring the environment to be re-started.  It also supports remote deployment, a feature that is essential in large computing environments. 
• The OSGi container has a light weight model to publish, find and bind services in a very efficient way. This allows for runtime introduction of services and much cleaner separation between internal code and external interfaces.   

Remember, the OSGi technology originated in the embedded device world where multiple companies were writing code to run on one device.  The resulting solutions are uniquely applicable to a service-oriented architecture environment where the goal is similar:  to deploy software as modules on the fly, without causing too much overhead or complexity. 

It’s time that enterprise software open their eyes to the lessons learned of the device market. Widespread adoption of standards like OSGi will help us write fully modular, service-oriented application software for the enterprise. 

For more information on OSGi, visit:

• OSGi Aliance
• Eclipse foundation Equinox
• Apache foundation Felix
  
• Spring Framework

Posted by Helgi Sigurdsson, Chief Architect

Earlier, I posted about why SOA was important, specifically in how it can help customers ease the burden of upgrading their systems and extend the usefulness of their existing applications. I’d like to talk a little more about this shift in development that is occurring to help make this possible – the move from application-centric development to SOA-centric development.

In the application-centric approach, the vendor releases regular updates to your software. Sometimes these are major upgrades but more often they are minor features or bug fixes. One of the problems with this approach is that there is no way to deliver an upgrade to the financial module, for instance, without affecting the other departments that depend on the ERP system.

This difficulty is a result of the way that ERP systems and enterprise applications evolved. In the early 1990’s, business process reengineering (BPR) became popular as means to increase time to market and competitiveness. To oversimplify, in BPR the processes flow from the HQ throughout the business to each operating unit. Beginning in the mid-90’s, ERP systems were all modified to meet the BPR paradigm. The approach was central control – a big, primary ERP solution with modules from the same vendor to support each function.

Since then, the business environment has changed dramatically. Probably the biggest change is globalization. Small to mid-sized enterprises are dealing with more complex business needs, distributed around the world and their business systems were developed together to meet these near-term challenges. Rampant consolidation in manufacturing and other industries has resulted in companies with multiple disparate business platforms, many of which were heavily customized or built in-house.

One other important factor occurred: the promise of centralized control ran up against the reality that no single vendor, and no single ERP system, could support all the needs of a customer. So customers turned to products from niche vendors for best-in-class solutions like supply chain management or financials to supplement their existing ERP.

The result is that today, almost all companies have heterogeneous environments with a mishmash of applications and business platforms. An application-centric deployment approach has made keeping them all in synchronization one big gigantic headache.

SOA-centric development can help fix this problem. This model doesn’t deliver new functionality to the core product or through tightly-coupled modules but as components that augment or enhance the ERP. They can operate as dependents to the core ERP, replacing functionality that used to reside in the big blob, or independently to support a completely new set of business processes. This model gives customers much more flexibility as to when and how they adopt new functionality, allowing IT to respond with standardized solutions much quicker.

The real transformation here is that the ERP system, as we know it, will become a thing of the past. This has already been happening to some degree but too many vendors are clinging to the old paradigm of central control, largely because they’re still rooted in business paradigms from the 1990’s. The reality today is that businesses operate centrally and distributed, so their enterprises applications must be able to do so too. (In a later post, I will talk about this concept in more detail.)

This will not happen overnight but gradually. Large enterprise applications will remain a part of the IT landscape for a long time, and we must support those with feature pack upgrades. Over time, componentization will make this a much easier process.

Darwin is often misquoted as saying “survival of the fittest.” In actuality, in Darwinism, it isn’t the fittest species that survives, it’s the one that’s most able to adapt to environmental change. Today, the business environment includes trends like globalization and collaboration. I can’t predict what companies and industries will face 10, 20 or 30 years from now. I do know that we can’t just repeat the development sins of the past and leave customers stuck when the business environment inevitably shifts again. That’s the beauty of SOA-centric development - customers can remain agile and adapt to whatever environmental changes the future holds.

Regards,

Bruce

Posted by Bruce Gordon, CTO