Mindset of Companies

First thought, do companies too have mindset? Entirely based on my own experience, I agree, companies have mindset. I am being lucky to work in companies with different mindset.

Second thought, Is it possible to categorize the mindset? It could be based on size, domain, geography, business model and vision. Most popular or known to me ;) categorization is based on business model like Product, Service and End user companies. Another popular one is based on size like Start ups, mid size or large Enterprises.

Now further talking about the Mindset based on business model. We all agree that Product and Service companies have different way of working. What about End user companies? These companies who don’t have IT as there core business and still build there own IT systems. If I put the Product and Service companies on opposite ends and now want to put End user companies between these two ends. Will End User Company aligns more to Product or Service Company? Thought is still vague, context and taxonomy is missing. Lets define in next paragraph.

Product companies generally have better vision and strategy. They have more focus on non functional aspect of IT system like extensibility, flexibility, modifiability, manageability, scalability etc. Service companies generally have wider experience of domains & technologies. They maintain the resource pools. They have more focus on delivery. Due to this non functional aspect gets less attention unless conveyed and agreed before signing off. Any changes after delivery means more revenue for Service Company.

Now, lets again think about End User Company, they are building systems for themselves in competitive market. This means they have to focus on Time to Market and aligns more to Service Company. But they have to maintain the system after delivery too. They can’t ignore the truth; maintenance & enhancements cost is much more than original development cost. This is fact and leads to conclusion that End User Company should be more aligned to Product Company Mindset.

Tactical Projects and Flyover in City

Just a thought, if Enterprise Architecture is analogous to City planning than Tactical project becomes analogous to flyover in City.

Flyover is constructed to reduce the bottleneck at one junction/crossing. Similarly Tactical project is executed to provide the short term solutions.

Flyover results into traffic jam on subsequent crossing after the flyover. Now we need to build another flyover to remove this bottleneck. Is it right approach? Or do we need long term planning to handle increasing traffic and a better public transport to take care of public. A better infrastructure and proper city blueprint to avoid all these traffic jams.

Same thing happens to Tactical project, which results into another tactical and another tactical. We need Enterprise Architecture to prepare Blueprint and vision of enterprise. This will help in reducing risk and cost of IT.

Improving Architectural Skill

Few tools to improve the Architectural skills are -
1. Reading books & best practices
2. Defining & Assurance of System Architecture
3. Attending seminars & conferences
4. Discussions with experienced Architects, colleagues & team
5. Reading white papers & blogs
6. Writing blogs and books
7. Registering for daily updates on technology and domains from Internet sites

Fastest way to improve skills is through point number 4, Dangerous way is to be dependent only on point number 1, Slowest & safest way is through point 2 and Impressive way is through point number 3.

ROI from Enterprise Architecture

It is difficult task to measure the ROI on Enterprise Architecture. Few activities of Enterprise Architecture includes -
1) Defining standards and guidelines.
2) Preparing reference architecture
3) Defining and maintaining IT roadmap
4) Governance activities.
5) Consultancy
6) Defining Strategy for moving from "as-is" to "to-be" architecture

Point number 1 and 2 produces various kinds of artifacts about Application, Information, SOA, Security, Content Management, B2B architectures. Various teams refers to these document and extend project architecture from these artifacts.
ROI - Is it possible to find out how reference architecture benefits the project architecture. How it saves time, add value, improve quality of project?

Point number 3 produces the IT roadmap for different elements across the layers. Any project should refer to this roadmap before finalizing the technology stack and aligns with it.
ROI - Is it possible to find out the operational and maintenance cost saved by aligning with predefined roadmap? Is it possible to find the effort saved by project when it adopt the preferred technology from roadmap instead of evaluating different products, technology and protocols.

Point number 4 includes activities like reviewing and approving architecture for projects. Assuring that projects are following standards and guidelines.
ROI - Is it possible to find the value of improved quality in project due to assurance from EA?

Point number 5 includes EA mentoring, coaching and guiding Solution Architects to align with standards, directions to follow best practices, refinement of the solution architecture of projects.
ROI - Is it possible to find the whether directions were right or wrong, whether they are adopted or not?

Point number 6 requires vision and leadership qualities. EA defines the long term strategy inline with Business Architecture. This helps in reducing the cost of IT in long term. It increases the agility of business. It simplify and standardize the architecture and implicitly increasing the stability, flexibility and extensibility of IT.

Above points shows lot of activities, but is it possible to measure the extent of benefits from these points. These benefits increase with time, they are like snowball which gathers momentum and becomes bigger as it falls. All these points prevents problems to occur in future.

May be it is easy to measure the benefits at enterprise level instead of project level. Identifying major architecture issues in enterprise like re engineering of legacy application, producing enterprise level reusable components, product engineering, improving integration of various application or deciding Build vs Buy. All these benefits of EA provides the ROI and help in building the metrices for EA ROI.

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

Shelf life of Software Project

A IT team develops a project and it is deployed. How long the application is going to be in production? Most the time average life of software project is around 3 years.

After 3 years, project might require a major upgrade and re-engineering in terms of technology and business.

Most of time systems wants to upgrade the system. There can be multiple reasons like
- infrastructure has reached end of life.
- it is not possible to extend the functionality. Application has become so brittle and requires lot of maintenance.
- it is not possible to satisfy the performance and scalability needs of business in near future.

Sometimes business wants to change the business process drastically. It is difficult to change the existing application. The only option left is to build a new application.

Now a new huge investment is required to create a new application silo. Oops !! Not again.

We all understand now that moment is right to increase the shelf life of software project. It could be possible by adopting SOA. Loose coupling between services provides to opportunity to increase the shelf life of software project.

An interesting thought, think about the layered architecture. Top layers have much lesser shelf life in comparison to layers below. Presentation tiers expires much before the Data tier.

Let's Enjoy Coffee

Good story -

A group of alumni, highly established in their careers, got together to visit their old university professor. Conversation soon turned into complaints about stress in work and life. Offering his guests coffee, the professor went into the kitchen. He returned with a large pot of coffee and an assortment of cups: porcelain, plastic, glass, crystal- some plain looking, some expensive, some exquisite – and asked them to help themselves to coffee.

When all the students had a cup of coffee in hand, the professor said: "If you noticed, all the nice looking expensive cups were taken up, leaving behind the plain and cheap ones. While it is normal for you to want only the best for yourselves, you were more concerned about comparing your cups but what you really wanted was coffee. Yet you spent all your time eyeing each other's cups.

Now if life is coffee, then the jobs, money and position in society are the cups. They are just tools to contain Life, but cannot really change the quality of Life. Sometimes, by over concentrating on the cup, we fail to enjoy the coffee."

Empires Of The Mind by Denis Waitley

I am currently reading "Empires of the Mind" by Denis Waitley.

Few excellent excerpts from the book -

Y'day natural resources defined power. Today knowledge is power.
Y'day hierarchy was the model. Today synergy is the mandate.
Y'day leaders commanded and controlled. Today leaders empower and coach.
Y'day employees took orders. Today teams make decision.

Book defines three prejudices to avoid
- The Rut of Average
- The Rut of Conventional Wisdom
- The Rut of Group-Think

A Leader's Critical Traits
- Self confidence
- Mental toughness
- Ambition to achieve

Life is like a field of newly fallen snow;
where I choose to walk, every step will show.

The Four legs of Value
- A sense of Belonging
- A sense of Individual Identity
- A sense of Worthiness
- A sense of Control & Competence

The 3-D vision of Leaders
- Viewing failures as not to be repeated learning experiences.
- Reinforcing past success to nourish confidence for taking new risks.
- Imagining future successes as real, despite the unknowns.

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.

SOA Repository

Todd Biske blog on Master Metadata/Policy Management escalates the very valid point in space of SOA.

Repository/Registry is one of the building blocks on SOA roadmap for any Enterprise. Foundation of SOA is based on Loosely Coupled principle. Vendor specific central repository violates the SOA driving principle.

Enterprises should create standards & guidelines for the central repository and moreover, for the services which could be added in repository itself.

Please see blog entry Empty Registry Syndrome for more details.

My chance to donate $25

James McGovern posts India, Outsourcing and Morality promises to donate $25 for track backs.

Not going into details of benefits and risks of outsourcing to India. I want to put forward my opinion.

Newton principle - For every action, there is an equal and opposite reaction.

On similar lines, it is also true that For every action, there are positive and negative reactions. Please also put forward the positive reactions. It will help us to find whether glass is half empty or half full.

Story about a sweet couple (OOAD and Business Analyst)

Once upon time, technologist OOAD met visionary BA. We all know opposite attracts, they were surprised to see the differences among each other. OOAD used to do work without thinking and BA only thinks and no work.

But they were destined to work together for many years. As time passes by, they fell in love with each other. Now both of them are trying to live together and are blessed with two prodigy sons. Currently, these kids are undergoing training in big enterprises.

Let me tell you little bit about them before introducing -
1. Put both of them on any project and forget about project. Only God knows when they will deliver it.

2. It is hard to measure how much work they have completed.

3. They take guidance from their parents but their way of working is totally different.

4. Both of them are very naughty and it is quite hard to understand what they are delivering.

5. They are too young and new to world. It is hard to have confidence in them. Sometime it gives impression that they will fail.

Some wisdom - give them space and time, let them grow with time and they are destined to change the world. Trust them. Two sons are SOA and Enterprise Architecture.

Attended SOA conference

SOA conference was organized by iCMG and Clive Finkelstein, MD, IES presented his views on Enterprise SOA. It encompasses sessions on EAI concepts, SOA & Web Services, Rapid Delivery using SOA and BPM, New Directions for ERP & Legacy.

I am quite impressed by Sunil Dutt Jha, CEO of iCMG.

Avoid burning your hands

Please avoid reading this entry if you think you are creative enough to find a new way to burn hand.

It is desirable nowadays that Architect not only know the Patterns but also Anti-Patterns. Similarly, understand the benefits of SOA and adopt it. But also be sure to research on pitfalls and risk associated with SOA.

Few points to avoid burning hands with SOA flame -
1. No Big Bang - Avoid this theory in Software industry, this is root of hundreds of failures.
2. SOA is concept - Never in software industry, there was a concept which has such an impact. Try to find the right technique to realize the concept in real world. Web Service is not only one.
3. Sell SOA - Everyone in enterprise is stakeholder of SOA. Sell to everyone for success.
4. Never ending SOA - Find out where your Enterprise stand in SOA maturity model.
5. Think end to end - Every project has functional and non functional requirement. Don't miss SOA non functional requirements - Performance and Security.

Who is this Enterprise Architect?

A good white paper from Guy Hoffman on role of Enterprise Architect.
Who is this Enterprise Architect?