Enterprise 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.

 

 

 

4 things you need to do in your next software selection project & 4 things you need to stop doing

on Saturday, 07 September 2013. Posted in Blog, Enterprise Architecture

4 things you need to do in your next software selection project & 4 things you need to stop doing

 

 

                                                         Software selection is a tricky and strategic process for any corporation. Here are 4 tips, on how to tackle a system selection process:  

1- The system selection process should follow a fact based approach. Gather Application or functional requirements via interviews and workshops from various groups like Operations, Finance, Marketing, and IT. These requirements should provide the basis for the selection. 

2- Employees in various functional areas, including Business Verticals, CRM, BI,ERP or any other type of system of engagement should participate to determine which value add features should be included in the selection criteria process. Through primary and secondary research (e.g. analyst reviews, vendor calls, subject matter expert reviews, independent consultants, vendor websites, etc.), select three to four vendors to issue the selection and invite them to demonstrate their offering.

3- Have a consistent approach for vendor selection analysis, a scoring schedule with weightings should be developed and validated internally. Further, scoring criteria should be established to evaluate the vendor’s software response.

4- Based on the scoring results and qualitative assessment of the vendors’ response and product demonstrations, short list two vendors and perform a total cost of ownership and a internal high level implementation plan. An important rule never select a software that has no product roadmap.

 

Below are some of the most common slipups, If you see your organization doing any of the following, take action quickly!

1- Not knowing up front the full Total Cost of Ownership . A previous client called me last week and was shocked to learn that their perfect $80K open source solution would cost $700K to make useful in their environment and another $250K annually to support. Make sure you perform a TCO.

2- Believing that newer technology will fix business problems is a trap that organizations repeatedly fall into

3- A software selection process that assumes the consent of other stakeholders without their involvement can easily get derailed. I know of several projects that experienced considerable delays after purchase or the software was put on the shelf do to internal reasons.

4- One that is often forgotten, not paying particular attention to integration points, the software selected must fit within your company’s spiderweb architecture.

Feel free to share any useful tips you've experienced.

 

Architecture for the cloud; Tips to build and deploy your cloud based applications

on Friday, 12 April 2013. Posted in Enterprise Software , Featured, Solution & Business Architecture, Enterprise Architecture

Architecture for the cloud; Tips to build and deploy your cloud based applications

The cloud and cloud-based solutions are here to stay. This will continue to drive business solutions for a long time. Why? Clear and measurable benefits below i believe are the top 4 reasons :

1- Almost zero upfront infrastructure investment

2- Just-in-time Infrastructure

3- More efficient resource utilization

4- The possibility of usage-based costing on your back office applications

Cloud is a disruptive force. However, the cloud’s “Achilles heel” is a lack of integration with the rest of the enterprise. Realizing its full potential relies, for the foreseeable future, on integrating data in the cloud with on-premise applications and databases.

Today’s enterprise cloud initiatives require decoupled data systems working together , without the need for personnel and other resources to set up and maintain them , making integration key to a successful deployment.

Most companies cannot and will not abandon their previous IT investments to make the leap to the cloud all at once. Instead, there is more likely to be a gradual shift in business processes to the cloud over time, similar by nature to a perpetual proof of concept.

As the cloud delivers on its promise, more processes will be shifted to this computing model. Complexity and diminished ROI will be the consequence when long-term strategy and goals are not implemented in advance. Put simply: integration needs to be a forefront, not on the afterthought of your project strategy.

Always design for failure, be a pessimist when designing architectures in the cloud; assume things will fail. In other words, always design, implement and deploy for automated recovery from failure.

In particular, assume that your hardware will fail. Assume that outages will occur. Assume that some disaster will strike your application. Assume that you will be slammed with more than the expected number of requests per second some day. Assume that with time your application software will fail too. By being a pessimist, you end up thinking about recovery strategies during design time, which helps in designing an overall system better.

If you realize that things fail over time and incorporate that thinking into your architecture, build mechanisms to handle that failure before disaster strikes to deal with a scalable infrastructure, you will end up creating a fault-tolerant architecture that is optimized for the cloud.

Questions that you need to ask: What happens if a node in your system fails? How do you recognize that failure? How do I replace that node? What kind of scenarios do I have to plan for? What are my single points of failure? If a load balancer is sitting in front of an array of application servers, what if that load balancer fails? If there are master and slaves in your architecture, what if the master node fails? How does the failover occur and how is a new slave instantiated and brought into sync with the master?

Just like designing for hardware failure, you have to also design for software failure.

Below is a baseline to help you consider all the moving parts required to build and deploy your cloud based applications.

 appsconsultantcloudapps

Lastly build process threads that resume on reboot and good cloud architecture should not be impacted to reboots and re-launches.

Like it or not, the cloud is a disruptive force, that i think will require us to move towards a more data centric business model.

Like usual, please share your thoughts and experiences

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.

Difference between enterprise, solution and application architects

on Tuesday, 01 January 2013. Posted in Blog, Enterprise Architecture

Enterprise Architect - Maps the business to the IT solution at the top level. Ensures all business objectives are met with the solution. This can include business processes, standards and best practices, reference models and can span multiple technologies and technical disciplines.

Solutions Architect - Drives the next level of the solution and typically focuses on the integration aspects into an enterprise of a specific component of the overall technical solution. IT can be one specific technology, application or component.

Application Architect - Just as it implies, it is your primary expert in a specified discipline or application.

The difference between MDM Systems and Data Warehouses

on Tuesday, 01 January 2013. Posted in Blog, Enterprise Architecture

In many ways, the processes are similar to those used in populating a data warehouse or datamart, particularly with the consolidation style of MDM; however, there are differences:

Volume and Type of Data: MDM systems involve only the master data, not terabytes of transaction data (such as telecommunication companies' call detail records), which may need to be stored at the detail level, in addition to various levels of aggregation for analysis purposes.

Database Design: The master data is typically held in a relatively normalized form, whereasmany analytical systems depend on specialized designs, such as star schemas to improve analytical performance.

Use of the Data: MDM reconciles semantic differences to give a single view of master data,usually for operational purposes, which is independent of any single application system. Datawarehousing supports BI and analytics, but does not usually support transactional activities. MDM systems and data warehouses are complementary, and the introduction of MDM systems into the operational area should reduce the work required to integrate and consolidate master data as it's prepared for loading into the data warehouse.

Information Quality

on Tuesday, 01 January 2013. Posted in Blog, Enterprise Architecture

 

Leading companies must implement a successful performance management framework and integrate it to their application architecture to improve on their information quality. Data especially in these times where financial data will be even more scrutinized, this data must be fitted and intended to be used in operations, decision making and planning for any type of business or corporation.

 application architecture

 
 

15 Items that should be tackled when dealing with enterprise applications

on Tuesday, 01 January 2013. Posted in Blog, Enterprise Architecture

 
Planning to implement an enterprise application such as SAP or Oracle you needs proper validations and requirements. Here is what I recommend as a preliminary checklist:

Scope Checklist

Item # Description Due Date Recommended Action Date Completed
1 Project scope is clearly documented.      
2 Project scope is clearly understood.      
3 A project charter has been developed and signed off by Deloitte and by the client.      
4 The project charter follows project management guidelines.      
5 The project charter is inclusive enough to cover risk.      
6 The project charter is reviewed and updated as needed.      
7 A scope management strategy is in place.      
8 A change request process exists.      
9 A change request log exists and is regularly updated.      
10 A file is maintained of change request forms.      
11 The impact of change requests is determined through quantitative analysis and is fully documented.      
12 A change control and tracking process and tool is in place.      
13 A process exists for communicating project scope and scope changes to team members.      
14 The status of change requests is regularly communicated to the project team and steering committees.      
15 The financial impact of scope changes is accurately determined.      

 

Enterprise Project Guiding Principles

on Tuesday, 01 January 2013. Posted in Blog, Enterprise Architecture

 

The following higher level “Guiding Principles” should be used to help shape key decisions as to which software components would deliver functional requirements to a Business Transformation.  Underpinning these guiding principles are some design principles that address specific areas of the solution. These design principles at a higher-level principle are:

             Buy vs. Build - Where possible use a suite rather than the development of bespoke applications. This helps to reduce delivery risk and total cost of ownership;

             Configuration, not Customization - The approach should emphasize “Configuration” rather than “Customization”.  This will help to reduce the implementation timescales, reduce some of the risk associated with software development, and make future changes easier to undertake;

             Good Enough vs. Best of Breed - Solutions should be selected based on them being "Good Enough" to meet Business Needs rather than selecting "Best of Breed."  This prevents over-engineered solutions that deliver minimal additional business benefit;

             Integrated, Resilient and Robust Technology Architecture – The approach to the choice of hardware, software and operating systems should be based on:

             The need to provide architecture that is aligned to the Clients Corporate Technology Framework; (important to listen and respect roadmap)

             The need to provide architecture components that are recognized as reliable choices for mission critical business solutions;

             The need to integrate new architectural components with existing applications using a robust and open middleware platform; and

             The need to minimize data duplication and minimize the risk of loss of data quality.

             Use of Open Standards – The approach to the suggested System Architecture should be based on the use of open standards wherever possible to minimize development time and costs as well as providing a future proof architecture.  In addition, the use of open standards ensures that the resources required to implement and support the architecture going forward do not require specialized knowledge of particular (proprietary) standards.  This minimizes the associated learning and development costs, allowing the focus to be on delivering the functionality required by Business Transformation.

 

Why ERP information is important for executive decision making

on Tuesday, 01 January 2013. Posted in Blog, Enterprise Architecture

 

Depending on the economy conditions, executives want information fast, especially when competition is tough.

When the economy is growing they look at employee satisfaction, market share, inventory levels, supplier data and simulations of company plans. When the economy is down they look at receivables/payables, budget/spending/costs, cash flow, operational risk, employee performance including productivity.

ERP data must balance broad, long- term project vision offering concrete, near term wins.I think companies thought 10 years ago the systems put in place would provide uniform and trustworthy data and yes ERP was able to provide that visibility, but I think we can’t ignore the human nature in corporations, I still see it today, If we get data that says you did a really good job this month then we trust the data, but if the data says we did a bad job this month we tend not to trust it, or question it.

The aim of enterprise data should be to enable faster decision making.

Once you've made your decision you need to put it into action. Don't worry about your decision being 100% full proof. Until you put your decision into motion you will not know the results of your action. Monitor your decision and make the necessary adjustments as you go along if you need to.

Here is a simple guideline you can use to help you when making decisions, it's called OAR.

O= Objectives that you are seeking.

A= Alternative choices that are available to you.

R= Risk that go along with the alternative choices.

Using these decision making tips can help you avoid worry and redirect your energy to the areas you need in order to make the best decisions possible.

The time to speed up important information is before it’s needed, not after. When crisis arrive it’s too late and slow data would have contributed to the problem.

 

 

Operationalize your Companies IT strategy

on Tuesday, 01 January 2013. Posted in Blog, Enterprise Architecture

 

Corporate strategic planning is the process of devising a plan of offensive and defensive actions intended to maintain and build competitive advantage over the competition. 

For strategy to be successfully implemented, it must be linked and aligned to all aspects of operations through a method that addresses risks, manages financial constraints and adheres to an ever increasingly complex maze of legal and regulatory requirements. 

Regardless of your organization’s size, industry or business model - strategic planning and well-executed implementation play critical roles in establishing and maintaining long-term growth and profitability.

Practical tips on ways to start operationalizing your IT strategy

IT_Strategy

 

 

10 tips for a successful enterprise wide project

on Tuesday, 01 January 2013. Posted in Blog, Enterprise Architecture

 

 

Enterprise projects success lies in the details. Below are some of my tips and hindsight’s in delivering these type of projects and what skills are needed to achieve stellar results without wasting time and money.

1)      Remain open-minded and flexible. Remember, change is inevitable.

2)      Pareto’s law states that 80 percent of our output is generated by 20 percent of our efforts. Time management is the key for your enterprise management project to be successful.

3)      Division of Work This is the ability to break down large tasks into sub-tasks that can be assigned to individual employees. It’s a tricky skill — maybe more of an art than a science. Ideally you want to figure out how to accomplish a large objective by dividing the work up into manageable tasks.

4)      Tag each team member using the DISC method: DISC is a quadrant behavioral model based on the work of Dr. William Moulton Marston (1893–1947) to examine the behavior of individuals in their project environment .It therefore focuses on the styles and preferences of such behavior.

disc_method

 

5)      Be yourself, don’t fall for the don’t smile to move up comments, or not to be kind instead be clever. Emphasize kindness, empathy, quality and decision making with your project to establish strong teamwork.

 

6)      A Commitment to the Truth. You’ll find that the higher you are in the management hierarchy, the less likely you are to be in touch with reality. Managers get a lot of brown-nosing, and people tend to sugar-coat the news and tell managers what they want to hear. The only way you’ll get the truth is if you insist on it. Listen to what people tell you, and ask questions to probe for the truth.  Develop information sources outside of the chain of command and regularly listen to those sources as well. Make sure you know the truth — even if it’s not good news.

7)     You must adapt to solve-complex problems and make decisions

8)      Conceptual, the senior levels on the project must see the organisation as a whole. In other words, there has to be some knowledge of the organisation and what it does and how it interacts with other organisations.

9)      Planning, It is one of the important manager skills which need to be possessed by a successful enterprise project team . The goal / target set by the project is the focus of all planning activities. Forecasting and predicting the consequences of a particular step or action should be taken into account. It is therefore an important part of planning. The activity of planning also involves the process of analysis of data / information. Analyzing the information helps in taking decisions.

10)  Technical Skills. Since majority of the organizations today depend upon specialized environments to carry on their activities, it has become mandatory for enterprise wide project members to have adequate knowledge of their environment, technical skills along with the basic management skills are a must.

 

 

Copyright 2015 Appsconsultant.com. All rights reserved.