SOA in MOE and LOE

More acronyms - MOE and LOE. May be due to my roots in Telcom domain, I am used to acronym in day to day life. MOE means Management Oriented Enterprise and LOE means Leadership Oriented Enterprise.

MOE is basically a type of culture prevalent in Enterprise. In this type of Enterprise, there exists lot of committees. Every decision is approved by hierarchy of people. Decisions are based on big reports. Long discussions take place to improve the efficiencies. Every big enterprise has processes. In this enterprise, employees follows all the processes to complete milestones. It helps to check the progress but the value of each step in process is not evaluated. Employees just complete the activity to tick the completeness. Delivery is primary focus.

LOE is another type of culture prevalent in Enterprise. In this type of there exists Leaders. Leaders at all levels. These Enterprises also creates lot of small committees. These committees come up with small action items. They believe in pilots, POC, prototypes instead of big reports. Long discussions too happens but with actionable outputs. Processes are followed and employees try to add value in each step. Quality is primary focus.

Somehow, I feel MOE adopts top down approach of SOA and LOE adopts bottom up approach due its culture. A push for top down in LOE is going to be much more successful than in MOE.

Assumptions in Software Project

Assumptions in software projects become the facts with the time. There is nothing wrong with assumptions. They help us to move forward in software project. The problem arises when we forget that assumptions are not facts. We should be prepared for the unexpected outcome of assumptions.

A short story on assumptions and how they work from "The Art of Negotiating" by Gerard I.Nierenberg -

A husband was watching his wife as she prepared a roast for the evening meal. After placing the roast on the cutting board, the wife cut the first slice and dropped it in the refuse can.

"Why did you do that, dear?" the husband asked. "I don't know," was the answer. "My mother always did it". The next time he saw his mother-in-law, the husband asked if she always removed the first slice from the roast before cooking it. "Yes," was the reply. "My mother always did it." So the husband, intrigued, called up his wife's grandmother. That elderly lady explained, "Oh, yes, I always removed the end slice from the roast because the pan I cooked it in was too small."

CIO/CTO Office and Enterprise Architecture

I have limited knowledge and trying to understand the synergy between CTO/CIO office and Enterprise Architecture.

There are multiple support units in IT organization who helps delivery teams to reduce cost and better align with business. Units like Quality, System Operations, Security, Enterprise Architecture, Testing, Business Analyst, Data Engineering, Application Engineering and PMO office. How CIO/CTO office provides the common platform where all these team representative meets to evaluate the current state of IT and defines and leads to the future state?

Next question is to whom Head of Enterprise Architecture reports and how the CTO/CIO could extract optimum benefits from EA team. There are still unanswered questions like whether EA aligns better with Business or Delivery teams. A tilt towards business make EA more like Business Architects and other tilt towards the Delivery team moves EA's to Consultancy role. The focus of EA shifts from enterprise to projects. This wide spectrum is challenge, opportunity and concern for EA teams.

Again with my limited knowledge, I think most companies don't have EA function and who possesses this function are still trying to find a suitable place to fit the EA in organization chart.

Note: In above blog, I have typically avoided the differences between CIO and CTO. For more details on differences, please refer following links - Whatever happened to CTO role? and CIO vs CTO. Secondly, I have excluded product organizations from discussion and talking about IT organizations.

Attended PMP training

Another enriching experience, I attended PMP training conducted by Upendra Giri, Founder CEO of www.astrowix.com.

To envisage the entire project life cycle is an art. A effective monitoring and controlling is integral part during execution of the project. It is absolutely necessary for on time delivery with high quality. It looks quite basic and simple principle. But it is missing in multiple projects.

Now, I better understand the words like PERT & CPM, Status reporting benefits, Costing & Scoping, Communication plan, Lead and Lag, Resource levelling, Leadership styles, Assessment and Mitigation plan for Risk, Procurement, activity & resource planning etc

I scored 162 out of 200 (Highest in training class). Little bit confused, do I go for PMP certification from Project Management Institute. It is very well appreciated certificate. But as an Architect, how it will benefit me?

Who makes more MONEY in IT - Manager OR Architect ?

Architect dont talk about Money ;) They are saints who dont care about it.

Let's discuss about the common IT employee. He works for multiple reasons like fun, interest, satisfaction, no other choice, family, company, status, habbit, money etc. Now he has a choice to select management or technical ladder. One ladder takes to Manager role and other to Architect role. Both need management and leadership qualities. Out of multiple reasons, Money was one. Now question before IT employee is - Who makes more Money ?

I would love to know what we feel/experience across IT world.

What is more important for a project - Quality, Cost or Effort?

There are multiple objectives and goals for a team to achieve. And I concur that there exists a collective ownership for all objectives. But still for each objective there is prime stakeholder. This stakeholder persuade others to achieve this objective. Now coming to title of blog, what is more important for a project? I first list down the prime stakeholder for these objectives -

- Architect is main stakeholder of Quality (always busy to improve the quality by using different tools, Architecture document, better design, refactoring, automated unit test, reviews, POC's, continuous integration, increasing customer feedback, improving process)

- Business Manager is main stakeholder of Cost ( always busy in simplifying business case, selling flexible pluggable extensible & configurable components)

- Project Manager is main stakeholder of Effort (always busy in reducing timelines, parallel development, starting different activities simultaneously, change management, planning, scheduling, tracking, milestones setting)

So what's more important - whosoever is able to sell his viewpoint more convincingly ;)