Lessons Learned the hard way from a failed project – Do we learn from our mistakes

on Friday, 19 April 2013. Posted in SOA


People learn best from failure. It drives lessons home like nothing else. Here is an email from a reader:

From: *********** [mailto:***********]
Sent: April 16, 2013 6:33 PM
To: This email address is being protected from spambots. You need JavaScript enabled to view it.
Subject: Building a Centralized Architecture


Dear Alex,

Pursuant to our telephone conversation today, I did some internal research and we are mostly an Oracle ERP,EPM, (back office applications) with Microsoft and Linux OS, and SalesForce as our CRM. Our companies strategy changed to a more centralized vision, mostly because some big IT projects being executed by us the business went really bad.

The following products ***** finance, procurement, hrms functionalities were not functioning for days.*********

Top management reacted and shutdown these initiatives.The cost was many millions but an excellent lesson learned, for all of us.

Top 4 points: 1- We hired the wrong consultants friendships with management existed that flawed results 2- Groupthink no one dared to challenge status quo, all of us did not foster diverse thinking 3- Project management provided too much of a rosy picture on status reports. 4- Fingerpointing existed and we lacked project members having the walk the talk attitude.

We had to rollback to our previous systems, and then the project was stopped.

My question, we are looking to purchase an architecture methodology mostly to help the organizations grow from our slip-ups we are starting with our SOA approach, governance and SOA operations.

We are looking at Zachman, Gartners, Oracle or TOGAF. Can you provide us your viewpoint on which methodology would you use knowing abit our environment and company.




***Received approval to share this article from the reader.


 The lessons learned for all of us, in my view are as follows:

 1-      Sometimes you think you are so good and so far ahead of the curve that you fall right off the edge

2-      When a project is obviously doomed to failure, get out sooner rather than later.

3-      A square peg in a round hole won't fit any better as time goes on. Problems that go unaddressed will only get worse, not better, over time.


Here is my top 10 advice in an enterprise project environments with high stakes involved:

  1. Hire to elevate knowledge
  2. Stick to the facts always decide with data
  3. Respect your team and make it fun
  4. Listen, learn and execute
  5. Try simplicity every time - while it may sound easy, it's the hardest thing to practice and will force you to get creative every time
  6. Avoid buzzwords
  7. Forego your ego
  8. Walk the talk
  9. Enthusiasm is always infectious
  10. Never give up, nothing is impossible

My view on the SOA Architecture Methodology question

Often the most difficult and important task that any corporation must perform is to select and implement an all-encompassing architecture methodology.

My view all 4 architecture methodologies mentioned above (Zachman, TOGAF, Gartner and Oracle) offer a sound basis to build your company architecture methodology. The only tip ‘never take it as is always customize it to your corporations culture’.

In this case the corporation is in 10 countries and has revenues of about 130 million dollars. In my view they should go with Oracle’s Methodology since they’re back office applications are 90% Oracle based and it was given to them for free. By the way the Oracle architecture methodology in my view is inspired by the TOGAF Methodology.

When it comes to OUM (Oracles Unified Method) The SOA core workflow view answers their requirements .The SOA Workflow View is used to help organizations to execute projects within a SOA environment .

Here is an overall diagram: reference OUM Methodology – SOA Core Workflow View

 SOA Core Workflow VIEW - OUM

Overall, my view is that starting an enterprise project is not like everything else. Nothing important is all that easy. Work hard, Learn from mistakes, Be Optimistic, Try again and Face your fears.

As per SOA methodology, reflect on your corporation’s culture and take into consideration the internal decision making process and vision as per vendor neutrality.

Like always share your thoughts and experiences


on Tuesday, 01 January 2013. Posted in SOA

We are currently updating the website, so bear with us for a little while. 

With new features and more secure.

Hi and welcome to my new website.  Hope you will enjoy your stay and note that I added a couple of new sections so you can get to your information quickly,  Audio Podast , White papers, blog sections and feeds from other oracle websites.

Project and Enterprise SOA

on Tuesday, 01 January 2013. Posted in Blog, SOA




It is usually necessary for practical reasons to break the SOA into different pieces; otherwise it becomes too big and complex to be useful. At least two levels of SOA (project and enterprise) are required in order to provide different levels of abstraction in an enterprise of any size.The distinction between the project SOA and the enterprise SOA is akin to the distinction between building or district architecture and city planning. While a project SOA provides an overview of the software services to be used by a particular project it also includes further details that are relevant to that project. The objective of the project architecture is to guide a particular project by declaring which existing services are to be reused and which are to be newly developed.

An enterprise SOA stretches across all the projects in an enterprise – or, more commonly, a significant sub-set of the enterprise. The objectives of the enterprise SOA are to set a vision for service orientation that transcends the traditional barriers between business and IT, taking a business-driven approach as indicated by most software providers. Individual project SOAs should conform to the enterprise SOA.

Depending on your platform here are some interesting links

Link to Oracle SOA

Link to SAP SOA


SOA Architecture Strategy

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

Use industry best practices any new integration solution should be designed using SOA and principles.




  • Create services to represent business processes not API’s or methods.
  • Provide visibility to web services through a published web service catalog.
  • Modularize services by functionality, maintaining independence and therefore flexibility.
  • Use schema standards such as Open Applications Group (OAG) and design patterns to ensure technology agnosticism.
  • Divide processes into atomic single purpose independent services.
  • Ensure loose-coupling of systems by separating system specific translations and functions from generic business process services.
  • Utilize tools that readily enable SOA: WebLogic Integration (WLI) in conjunction with an Enterprise Service Bus (ESB).

SOA Question from South Africa

on Tuesday, 01 January 2013. Posted in Blog, SOA

-----Original Message-----
From: Nickens XXXXXXXXXX
Sent: October 19, 2012 2:26 PM
To: Alex Antonatos
Subject: Alex Antonatos: SOA Question

This is an enquiry e-mail via from:Nickens XXXXXXXXXXXX 

Hello Alex, 

We are a large mining global company in South Africa, and have mining operations in Botswana, Johannesburg, Nigeria, Asia and Europe. We have slowly been standardizing our products going from 3 ERP's to 2, 3BI to 1 and have successfully deployed SOA to help with the change.

My question or frustration should applications be choosing WSDL or REST when integrating into SOA Architecture 

Thank you in advance for your help, 






Nickens, Suppose for instance that your current service portfolio has 50 services, 30 of them may be using Web Services and the rest may be implemented using a combination of  (Representation State Transfer (REST) and Simple Object Access Protocol (SOAP), or you may take the decision to use Java mechanisms. SOA does not constrain you to use Web Services, SOAP or REST.

However using Web Services is a best practice with the use of Web Service Definition language (WSDL) is the fundamental aspect of what makes a WebService not SOAP or REST.

Let me pinpoint 2 important differences:

1) With Web Services you are requesting a service, with REST you are looking for a specific resource.

2) REST typically use HTTP as the transport, where SOAP has no restriction on a particular transport.

As you are a global corporation you will require a combination of both.  The internet has lots of good information on the differences, here’s one:

Kind regards,





ZOO Comment

Copyright 2018 All rights reserved.