Articles tagged with: solution architecture

Get rid of the lengthy COTS Feasibility Study, Interesting facts & data to make you think twice

on Friday, 30 May 2014. Posted in Blog, Enterprise Architecture

Get rid of the lengthy COTS Feasibility Study, Interesting facts & data to make you think twice

 

 

 

 

                                                       Feasibility studies permit planners to outline their ideas on paper before implementing them. This can reveal errors in project design before their implementation negatively affects the project. Applying the lessons gained from a feasibility study can significantly lower the project risks. In my view feasibility studies should never be longer than 4 months, no matter how big your project is let me explain:

The Feasibility study is not a sales pitch, way too often we focus on the COTS (Commercial off the shelf ) product, In my view, this is a fundamental mistake all these products work and are already integrated (PeopleSoft, Oracle EBS, Fusion,JDE, SAP, Siebel) it does not make sense any longer with the vast information out they’re to be completing Feasibility studies with full system analysis like Oracle or SAP that last longer than 4 months.

Why? I have yet to hear in my career that Oracle or SAP cannot perform a certain business function if not vanilla or with a RICE(Report-Interface-Conversion-Extension). Especially know that everyone has adopted a SOA more Open based Architecture.

Below is an email I received by an individual that gave me approval to print this email onto this article, he shares his experience about their feasibility study:

From: **************************************
Sent: ************************
To: Alex Antonatos [mailto: This email address is being protected from spambots. You need JavaScript enabled to view it. ]
Subject: RE: Oracle Fusion vs PSFT

 

Hi Alex,

Great read on your Fusion article, just to let you know we just performed a 10 Month feasibility study on PeopleSoft or Fusion and we came up with the similar conclusions as per your article.

The only thing that bothers me, we could of donated that money to a worthy cause. I think we spent almost a million dollars if you tally up the employees like myself hourly rate and some consultants that were with us.

I have been in the IT field for 25 years, and the end game is always the same ;consultant come in make the money and leave after 3-6 months to the next project and the employees get the s**t for why we spent so much money, and the employees are stuck to show the value add of the 10 month feasibility project.

On a side note, I really enjoy your blog and thank you for the whitepapers.

 

Best Regards,

***************************

***************************

***************************

***************************

***************************

***************************

***************************

 

In the case above, we all sense some passion&frustration, I dont blame him they spent over 1 million dollars to go ahead to say that PeopleSoft 9 or Fusion can integrate to the current landscape of systems. Same answer as day 1. They’re study presented risks and returns associated with the project so the prospective managers can evaluate them. Again in their case they also believed their Finance and HRMS systems where so different compared to the norm and fell into a sales pitch of functionalities.

Here are some more examples of long feasibility studies that went the wrong direction:

1) ERP implementation , business functions inability of Hershey to ship candys for Halloween (The Feasibility study was 10 months)

2) ERP Implementation Nike Losing major shoe orders (The Feasibility study was 9 months)

3) Foxmeyers failure to process financial information and orders (The Feasibility study was 11 months)

4) BSkyB (BSY) got a 318 Million pound settlement in 2010 for a COTS system that did not work (The Feasibility study was 13 months)

5) UK Government scraps a 12 Billion National Program to provide integrated electronic records (15 Month Feasibility)

6) State of California spent 300 Million dollars in implementing a COTS software (12 Month feasibility study)

Here are some practical tips and guidelines:

  1. Use social media, an example when i wrote the article about Fusion and asked people to share their go live experiences i received 87 emails in 72 hours. These answers helped me understand quickly the different strengths and weaknesses of the product.
  2. In my view, The acceptable level for any business feasibility of a COTS package should not be more than 4 months, but the appropriate risk rate will vary for each individual depending on their personal work situation. Less experience teams usually require more time to complete a COTS Feasibility study.
  3. No SALES Pitch, focus on the integration, economic viability and operational zing of the project
  4. Don’t expect perfection in a feasibility study this is the main reason it should be short and done quickly.
  5. Bottom lines there are dozens of reasons why a feasibility study can't be done in a shorter timeframe, but perhaps only one why it can. It’s up to you to decide whether you are going to search for a way to do it, or regularly settle for a handy excuse. Some companies fall into the trap and use the feasibility study more like a sales pitch . Don’t do it!.

I am a big fan of the feasibility study but it should be a quick study and low cost exercise to determine if your COTS project (Commercial Off the Shelf Product) makes sense to adopt it within your organization.

 

 

 

Best practices in solution architecture for Oracle EBS, OBI, Hyperion Planning

on Wednesday, 04 December 2013. Posted in Enterprise Software , Blog

Best practices in solution architecture for Oracle EBS, OBI, Hyperion Planning

A perfect design is an enemy of a good design. Often, we strive for a perfect design by customizing our systems, with what we currently know and forget quickly that the out of the box design may not provide the best solution to a given problem but it would probably have the best chance of meeting the schedule , regulatory compliance and cost constraints with acceptable quality.

I just completed US financial services solution architecture and noticing a trend with enterprise customers towards simplicity and making sure the business is provided tools to adapt to the new out of the box functionality reality. 2014 focus seems to be on essentials, mobile and providing a responsive design to the end user.

Having been lucky enough to have implemented multiple times EBS R12, Hyperion Products, OBI and CRM projects, I share some best practices on what in my view should not be modified and other areas that should be slightly improved from a business architecture standpoint:

 

Architecture OBI Hyperion  EBS

 

One question that comes often what is each product main purpose: here is a quick 1 liner on the products.

Hyperion Financial management is Oracle’s consolidation tool and statutory reporting

Hyperion Planning is the Strategic Planning, Budgeting and forecasting tool

Hyperion Financial Data Management is a tool to map different chart of accounts between source systems (EBS and non EBS applications) and HFM

Oracle EBS R12 is the ERP that store the Financial, Project, Procurement, Supply chain transactions

OBI Oracle Business Intelligence is the BI platform that stores the OLAP analytics, provides enterprise reporting, mobile BI and different scorecards.

When implementing your enterprise software keep in mind the following best practices:

1)  Times are changing; your approach to BI must change, Mobile Users Deserve the Same Quality of Browsing Experience as on your computer, one financial services company in the US is making sure most ERP, CRM transactions can be performed by mobile or tablet. Put in place mobile responsive design architecture when designing your solution. Your competitors are probably doing it or thinking about it. Technology has become the differentiator, not the business process.

2)  Capture integration requirements, then challenge all requirements that don’t respect the out of the box functionality, always make use of the product API’s to customize your solution if required. Focus on essential requirements only.

3) All enterprise software now integratre with Microsoft Excel, Microsoft’s classic spreadsheet program, is a favorite of sales and finance teams everywhere, use it to minimize change management

4)  One that I see often, not matching the growth strategy for the company to the capabilities of the system being implemented. Make sure everyone understands your functionality/ project scope and ROI to avoid the smoking mirror syndrome were the expectations and money spent do not correlate to the required outcome. Communicate with facts and data only!

Like usual please provide your thoughts and comments on solution architecture best practices.

 

 

7 Tips to Improve your Project Solution Architecture Outcome

on Wednesday, 23 October 2013. Posted in Enterprise Software , Solution & Business Architecture, Blog

7 Tips to Improve your Project Solution Architecture Outcome

The goal of architecture is to identify the requirements that affect the structure of the application and design a business solution.

 A well thought-out architecture should always consider these important principles:

   Build to change instead of build to last

   Understand the end user needs and the domain before designing components

   Identify sub-systems in your product and consider layers and components to abstract them and identify the key interfaces

   Use an incremental and iterative approach to designing the architecture

   Learn from company history, document your decisions and identify and mitigate key risks

But as we all know: every organization has its share of political drama: personalities clash, diverging agendas. Having worked at many companies here are some thoughts and tips to avoid architecture delays or having your project stopped:

 *** Communicate like you are a Teacher, not a Preacher

 A general assumption, architects are supposed to share their knowledge and experience. Failing to share that information is pretty much against the job description. But how you communicate that experience is the most important part of the job.  Think of your best teachers in school—did they ever go in front of the classroom and tell you how smart they were?  I don’t think so.  They found subtle ways to express their knowledge that encouraged learning and asking questions.

 Tip #1 that I often use , I start my sentences with ‘I think’ this will open discussion items and questions and encourage a two-way discussion.

 Tip #2 Architects are usually quite smart and have a breadth of knowledge but the tone, quality and delivery of the Information is more important than the content, try to always communicate like a teacher .

 

*** Standards apply to Architects, Developers and COE (Center of Excellence)– Don’t take the easy path take the smart path

 Enterprise architects put together standards documents that lay out , architecture patterns, coding conventions, infrastructure, source code nomenclature, and build structures.  But to publish those standardsand fail to hold yourself to them is the highest form of hypocrisy.  If you can’t follow a standard, why would you expect anyoneelse to follow it too?

An example, a company wanted to perform a point (system)to point (system) development, in this case standards existed to use web services with these systems, the development team took a quick decision and coded the point to point development and satisfied the business requirement. The director of the COE (Center of Excellence) did not realize an impact existed onto a surrounding system , the issue caused a security and reconciliation issue. In this case the cost to fix the data & interface was 4 times the initial budget.

 Tip #3 : By applying the standards to your work, you’re respecting the standards of the organization; you also see what will be painful for other groups. Respect your standards and reduce the power politics within your organization.

Tip #4 : Always try to eliminate 'it’s not my job” attitudes at your workplace, especially when you have the role of the architect.

 

***Command from the dugouts, not from the Ivory Tower

Not once, in any company I’ve ever worked with or for, did this idea bear positive fruit for the development teams involved.  Instead, these segregated groups architecture and development teams have generated one or more of the following:

 *        Contempt for the architecture because the developers had no say in

the architecture

*        Rejection of the framework because it was impractical to apply to

the project at hand

*        Blatant disregard for the standards set by architects because the architects did not have to respect company deadlines as a result of the delays introduced by their work

 Tip # 5: Architects should be a member of the project team, never as a visiting diplomat to the team.  Teams respect the opinion of someone who lives their daily reality side-by-side with them, not someone who hands them the Ten Commandments.

  *** Architecture teams that believe their involvement is limited to the design phase don’t really understand what it means to be an architect

 An example, when a building is being built, the architect is on site during the majority of the project, overseeing the effort at a high level, ensuring that little changes are not impacting the big picture.  All the while, the architect assists in solving problems that arise from his or her design from a practical standpoint, same as any enterprise software deployment

 In short, the architect’s involvement is continuous, not disconnected.

 Tip #6 : Make sure the architect is involved in the design, build and deployment phase.

 

***Documentation

Tip #7 : Always begin your intervention with a contextual diagram and perform a walk through with the team, don’t write too much text it may cause confusion at the beginning. Developers and implementers interact better with diagrams.

 For architecture projects to succeed there must be a partnership of developers,implementers and architects. Successful partnerships require two way communication and trust, none of which happens when someone acts like God’s gift to mankind, insists on his way or the highway and doesn’t actively get his hands dirty.

Feel free to share your tips , comments and thoughts.

 

 

Business architecture always adapt to your audience - 4 tips

on Thursday, 22 August 2013. Posted in Business Analysis, Solution & Business Architecture, Blog

Business architecture always adapt to your audience - 4 tips

 

Always make a point to understand your audience, audience analysis involves identifying the audience and adapting a speech to their interests, level of understanding, attitudes, and beliefs. Taking an audience-centered approach is important because your material effectiveness will be improved if the deliverable is created and delivered in an appropriate manner.

I have seen many times technical people speaking to the business and not talking at the right level and emphasizing technical information like security, protocols and interfaces. An example application A will push the actuals to application B (good) instead of saying Application A attributes are connecting to table AR_Actuals and the trigger releases the information into Application B table GL_Open_balances. 

Depending on your audience adapt your architecture diagrams accordingly.

In my view, here is a sample architecture of a business architecture diagram that will connect with business savvy people to initiate architecture discussions. here are my tips:

  1. A Business Architecture must be process centric
  2. Be able to apply enterprise-wide architecture and process-level models and techniques that are aligned to your roadmap
  3. Develop a measurable architecture for planning, budgeting, organization design, compliance, human change management, and the introduction of breakthrough technologies
  4. Be able to use an architecture model to accelerate capability change projects and model development

 architecture

 Do you have any favorite tips or would like to share your experience on this topic?

Oracle Fusion Applications Workflow for Project Implementation & answers to questions received by e-mail on Fusion

on Wednesday, 27 February 2013. Posted in Enterprise Software , Featured, fusion

Oracle Fusion Applications Workflow for Project Implementation & answers to questions received by e-mail on Fusion

 

 

We are now at release 6 of Oracle fusion applications (11.1.6), many questions have been raised on the implementation approach. Fusion don't forget is a combination of multiple Enterprise systems that Oracle acquired and yes Oracle took some of each to create Fusion.

Below is a visual diagram I created on the steps required to implement an instance of fusion applications:

 Oracle fusion apps implementaiton workflow

 

In general , it took me about 3 days to configure HCM and Financials, the functional configuration enables your Offerings and Functional Areas for implementation, and you select the Feature Choices, which typically enable you to integrate Offerings. Below is a screenshot

 

fusion apps setup

Question – What are some of the differences between EBS and Fusion Applications?

This questions comes often and people still believe no major changes exist,    below are 4 of them in the areas of Authentication, Authorization, Security and Segregation of duties.

 

E-Business

Fusion Application

Authentication

FND_USER

FMW(Fusion MiddleWare) OAM/LDAP

Authorization

AOL security model

FMW OPSS Oracle Platform Security Services

Security platform

Proprietary

FMW OPSS

Segregation Of Duties (SOD)

No functionality

Predefined SOD policies
Application Access Controls
Governor (AACG)

Question – In Fusion Applications Vision data does not exist anymore?

This is a common myth; here is a screenshot with some vision data

 fusion vision

Question 3 – Oracle Fusion Applications Documentation not available online?

Below is the link to Oracle Fusion Applications release 11.1.6

 fusion apps doc 11.1.6

http://docs.oracle.com/cd/E37583_01/index.htm

Oracle Fusion documentation is improving rapidly, it know include lots of detail with examples to help us take the right decisions.

 

 

Test drove for the last 6 months Oracle Fusion Applications, they have achieved Incredible Things, 7 Pros and 2 Challenges of Fusion Applications.

on Wednesday, 13 February 2013. Posted in fusion, Blog, Enterprise Architecture

Test drove for the last 6 months Oracle Fusion Applications, they have achieved Incredible Things, 7 Pros and 2 Challenges of Fusion Applications.

 

As most of you know for the past 6 months with some individuals in Palo Alto,CA. I have been testing, educating myself on the next generation of Oracle applications called Oracle Fusions Applications. What is Oracle Fusion Applications? It is inspired by the best of breed of Oracle’s application: Peoplesoft (HRMS), E-Business Suite (Financials), Primavera (Projects), JD Edwards (Manufacturing/Financials) and Siebel (Embedded analytics)

The question that everyone is asking should i stay on my current ERP or replace my systems with Fusion applications: (I must get an email every two weeks on this topic). Before i share my thoughts on this topic, let me share my experience for the last 6 months on the current version of the Fusion applications:

Pros

1)The response time is solid, look and feel is great.

 fusionalextest2147

2) They have incorporated a configuration setup workflow that makes it much easier to configure your module. Above screenshot I logged in with Fusion Functional Setup Manager (FSM) this is a one- stop shop for all implementation activities from planning to deployment. FSM is a separate module product, who manages all setups and all the various branches of products groups. Fusion includes FSM to allow implementation by others than the IT department or consultants. This includes plenty of checklists and simplifies the job of the project manager to setup and monitor the setup tasks as identified by Fusion itself. (Functional setup much quicker and easier to perform!)

3) What I appreciated the most was the export setup data, this functionality also allows users to easily migrate configurations from one instance to another (Test/ Production), works great did not encounter any major issues.

fusionalexexportsetups

 

4) Oracle Fusion Architecture provides an open architecture ecosystem, which is service & event- enabled.

5) Current present day applications have been on proprietary tools like People Tools, Forms, which require niche skill sets to manage and maintain.

6) Fusion has been developed; with Open standards based technology and is built on re-known Oracle Fusion Middleware (ADF, JAVA, SOA, BPEL, WEB 2.0 etc).

7) Currently CRM and HCM families are the most popular modules of Fusion, followed by Supply chain management (SCM).  Below are all the family products:

 fusionapplications

Where does PeopleSoft, EBS, Primavera, JDE and Siebel go from there? All these ERP’s had released a major version after the announcement of Fusion GA(General Availability), and there's no end in sight for future support(I guess until 2020). In fact, I think Oracle has good reason to keep these Enterprise systems going, even with Fusion now as an option.

I don't think Oracle is in a rush to try to get people to move to Fusion. PeopleSoft, EBS etc...They are very profitable business for them.

If you just look at PeopleSoft are far more profitable than Fusion precisely because the latter is so new. The dilemma for customers is when to opt for innovation over stability.

Oracle Fusion implementation can be done in 4 ways by

  1. Upgrading—Replacing an existing Oracle Applications instance with a new release (either a currently installed Oracle Applications version or Oracle Fusion Applications)
  2. Reimplementation—Treating an existing Oracle Applications installation as a “legacy system” and implementing some components of a live Oracle Fusion Applications installation or an entirely new Oracle Fusion Applications installation
  3. Coexistence—Adding Oracle Fusion Applications solutions to a customer’s existing Oracle Applications solutions, rather than upgrading or implementing new solutions in place of existing solutions
  4. Migration of data—Converting data from one Oracle instance to another Oracle instance by using Oracle’s Open Interfaces API and other Oracle or third-party conversion tools

I am strong believer of co-existence strategy and architecture for Oracle E-Business Suite, PeopleSoft, JD Edwards and Siebel apps and Fusion, for the following 3 reasons:

1- Risk mitigation, Fusion applications is still in my view a new product

2- You require revamping your technology skills within your organization to extend, maintain and support the various components of Oracle Fusion Applications here is my short list (A coexistence strategy can help you slowly adapt with the change of technologies):

  • SQL, PL/SQL, JAVA & java script
  • XML – Extended Markup Language
  • CSS – Cascading Style Sheets
  • XSL – Extensible Style sheet Language
  • ADF – Application Development Framework
  • JSF – Java Server Faces
  • Web Services
  • BPEL – Business Process Execution Language
  • AIA – Application Integration Architecture
  • Web Center
  • BI Publisher
  • OBIEE – Oracle Business Intelligence Enterprise Edition
  • Hyperion Essbase
  • WebLogic Server Administration
  • Oracle Identity Management

3- Most corporations have invested significant money in their current technologies, and will require a strong business case with facts and numbers on the added value of going to Fusion in a big bang approach.

Interest will remain high with Fusion applications and my predictions in the next 5-8 years everyone will be on Fusion similar model like SAP. Why 5-8 years? Most corporations require lots of inter connections to other systems (spider web architecture) and have invested in significant customizations to meet the corporations global business requirements.

My overall experience with the Fusion applications exceeded my expectations. Would appreciate to hear from clients and others that are live with Fusion.

Service Oriented Architecture (SOA)

on Tuesday, 01 January 2013. Posted in Solution & Business Architecture, Blog

SOA will dramatically change our working environments. Oracle SOA suite is the beginning of standards-based applications that are secured, managed and governed , and are spawned

by changes like Mergers & Acquisitions, regulatory compliance, and increased competition.  

With this in mind, we introduce the concept of a Service Oriented Architecture (SOA).

 

What is SOA it is a design blueprint for applications within an enterprise.
 

 

Corporations will adopt SOA, to increase their business agility, for faster response changes, increased technology asset reuse, reduced integration expenses, reduced business risk & exposure

The ability of SOA to change, evolve, and manage business processes throughout an

enterprise is changing the way IT works. SOA is enabling IT to operate as a

business unit. Alignment and accounting for IT investments is now based on business

strategies and transactions. SOA in an enterprise will identify and highlight

business dependencies and encourages cooperation and communication between

business units and IT.

 

SOA uses Services. Corporate applications evolve into organized collections of what are

referred to as “business services”. Looking at these applications from a service

orientation perspective closely maps to business initiatives and processes. So a

service can be payroll, or extending credit, or adding a new customer—it’s no longer

only a technical transactional process.


A well architected SOA provides top to bottom management visibilityof existing web services, so one doesn’t go on a “scavenger hunt” for any given

application. A SOA provides for a more rapid method of distributing applications and

increased agility. By leveraging, and the reuse of existing enterprise software,

infrastructure, and networking/bandwidth, the costs of custom integration and

interoperability are lowered. Manual tasks are reduced or eliminated. Compliance

within an organization’s industry is accomplished by exposing business

processes and reducing risks. For even greater cost savings, these

business services are reusable for many different applications both within and outside

of the enterprise without costly changes.

Most corporations have started to plan and implement a SOA adoption.

Copyright 2015 Appsconsultant.com. All rights reserved.