In Search of Patterns in the Enterprise

My understanding of the Enterprise Architect role improves with every quarter. For last few quarters, my focus was on Technology Architecture and Governance.

Its a good beginning for me to understand the Mutual Fund business domain. In my view, Enterprise Architect role demands good understanding of Business Architecture. And to add more, its easy to read the architecture domains as described in TOGAF framework as compared to analyse the complexity of inter-relationship between the architecture domains.

I have seen Enterprise objectives, vision and goals for very few companies and they look more or less same. And its interesting to find the pattern on how these are related to initiatives in the different Enterprise.

Another interesting place to find pattern is between the mapping of the Business process, applications and technology stack. And for the similar kind of business process in different business unit of same Enterprise which all applications and technology stacks are used.

Interestingly, I am still trying to identify the similar resolution pattern for the identical recurring problem at conceptual level in different units of the Enterprise.

May be Enterprises needs to define Architecture Policies, Standards, Best practices to abolish the pattern of re-inventing the solutions for the recurring problems at Enterprise level.

Thoughts on RIA

First thought which comes to mind is whether its a another buzzword and is it going to survive. My view is its going to survive and reason for this not that its cool or hot or bleeding edge technology. But the only driver behind its success would be "Customers are going to Love it". Its the way web is moving towards - a friendly, fast and fantastic user interface.

I don't understand the intricacies of RIA and I am not expert in it. But I understand fundamentally that Magic lies in Asynchronous XML messaging. It provides perception of site with hyper intelligence. There many flavours of RIA available in the market. Few famous one's are Adobe Flex, Microsoft SilverLight and JavaFX.

Now the challenge for an Enterprise, it is still emerging technology and not based on standards. Is it ready to be introduced in mission critical production environment? Benefits comes with calculated risk. Enterprises need to adopt these AJAX based technologies in less critical applications. Few examples of such selected applications may be for survey, selection of product, search screen, choice based on criteria and wizards. And above all, try to keep the number of AJAX toolkits as low as possible in Enterprise.

Stand up in Universe and find your value

Stand in big ground, raise your head and look at sky. Think how you can add value in this big ground? Move one level up, how much value you add in the area where the ground is located. Move up again, do you matter in context of city. At next level, do you matter in context of state level. Now think of country, how country is impacted by your actions. Is this the end? Not yet, think of continent, think of Mother Earth, how you add value to it. That still not over, how my existence matter in universe - May be Inconsequential.

Let try the same analogy in big enterprise. A developer working in a module of project. Module is kind of world to him. How his work impact the the whole project. This project is part of some program. Program is run by some business unit. Business unit belongs to some vertical. This vertical is part of regional unit. This regional unit again reports to headquarters in country. Country is just one of countries where MNC operates.

Is it possible one person, one team, one group, one unit creates ripple effect to make the Enterprise better? In the last I remember a quote, if you don't make a difference, you don't matter !!

Attempt to understand meaning of "Strategy"

My first attempt to understand the meaning of famous word "STRATEGY". I am using this word for quite sometime during my conversation with teams. Whenever I want to focus on some long term plan with expensive investment. To me, Strategy means to have plan and road map to execute plan with existing resources. With fast changing markets scenarios, one need strategic direction and tactical steps to move in right direction.

Furthermore, Strategy could devised at different level in organization for different purposes. It shows the path to reach the identified goals. Mostly organization devise corporate, business and system strategies.

Lets try to understand business strategy - It frequently contains simple and common objectives like generate revenue, increase profit margins, reduce total cost of ownership, improve stability, increase agility, create brand value, focus on people and processes, deliver results, innovate, become leader in flat world, motivate people to drive organization and lot many similar things.

On similar lines, IT drives the Technology strategy from Business strategy. It plans the future road map from current roadmap, create plans/steps to reach the long term objectives, better align with the business directions, increase reliability and availability, improve service levels and create governance mechanism.

Strategy looks quite common sense and most of companies have strategy in place on similar lines. But not all companies are excellent and growing at tremendous pace. What else is needed for business to succeed? May be a excellent implementation of strategy, people who believe in strategy, leaders who keep the whole team moving together in right direction and selection of right strategy at right time.

In Search of Excellence by Tom Peters

One more must read book. 7-S model is interesting and provides insight into the working of organization. This link shows the various models at organization, team and individual levels.

7-S model define the various elements which forms the organization. I am still trying to understand the various stages in the life of any organization. Is there exits a trend for stages during life of Organization? May be on the lines of Tuckman's team model.

Another team model worth reading is Situational Leadership.

Experience matters more than any theoretical knowledge. I think in Architect role, we get lot of opportunity to hone leadership & process management skills but people management skills take a backseat. In my view, People management skill is also important in long term and one should find ways to develop it.

The Google Story by David A. Vise

Not just another book. It looks more like a fiction. Google phenomenon happened during our lifetime and before our eyes. Its a inspirational story.

Sergey Brin and Larry Page are people of principles and beliefs. They have reaped benefits of economies of scales. Google is default search engine and have unique position. Power of Google lies in
- Search Engine business case i.e. Information and Search significance are directly proportional to each other, both are growing at fast pace.
- Secondly, in having a winning edge on technical front. Mammoth hardware clusters and creative software to harness the power to generate lightening results.
- and in the last, they are able to build a big brand name associated with high integrity, values and reach.

Lets end this blog entry with Google Motto "Don't be Evil".

Is productivity directly proportional to time?

Few Indian companies are thinking to increase weekly working hours from 40 to 50. In my view productivity is not directly proportional to number of hours spent in office. It could easily be improved by increasing the focus on doing right things and improving motivation of workforce. But by increasing number of hours would only increase the billable hours not productivity.

Quite opposite to study conducted by Gartner and trend suggest that weekly hours will reduce.

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.

Find how much you are addicted to blogging?

50%How Addicted to Blogging Are You?

Run a country without governance

Idea looks quite weird to run a Country without governance. Even thought is scary that if no governance is present in country, what will happen to state of a nation.

Think of a Country which is composed of States. And there is no central governance present, what will happen to States. Few States might be able to self govern, few will loose direction and few will become rogue States. With time, it will become difficult to manage the Country as a whole. Vision of country will be blurred and lost. States won't be able to leverage each other strengths. States will try to run their own charters and soon forget that they are part of Country. Most of States will have their own priorities, goals and budgets.

Still not convinced and think that Governance is overhead in a Country. Just for information, check the link Somalia , which is the only country in the world where there is no government.

Now just replace the Country with Enterprise and States with Projects. Hope you understand that missing governance in Enterprises is one of most common reason for complex IT state.

Candidate for the EDA

For a long time, I am reading excellent posts on SOA and EDA blog by Jack Van Hoof. EDA reminds me of Telecom domain. This domain is excellent candidate for EDA. Telecom network generates the events. These events are intercepted by application services like Prepaid, Ringback tone, Follow me, VPN etc.

Explaining my point with scenario like execution of Single Service -
Consider scenario where prepaid caller dials a called party number. A event is generated, service capture the calling party number and called party number. Based on called party number it routes the call. Now caller listens the ringing. Called party picks up the phone. Another event is generated. Service captures the events and starts charging. There is voice channel between caller and called party. After sometime, called party hangs the phone call. Another event is generated and service based on this event stops charging and persist the duration of call. In this flow, based on current event and last event result, application service executes the business logic. There is requirement for storing the state of call. This makes scenario little bit complex. Events cann't be consider stateless in real sense.

Execution of Multiple Services
In this case, one approach is to introduce Service Manager and this Service Manager further manages the interactions with several services and their sequencing.

In contrast with Enterprise application, Telecom applications are more chatty i.e. Events are too many and are of very short duration. Due to this, scalability and performance becomes burning issues. Secondly, all these events are in real time. While events are processed, customers are waiting for call to connect, waiting for ring back tone, announcements etc. It makes true testing ground for EDA.

In last, I feel, SOA and EDA could change the landscape of Telecom services. Niche companies could provide services like charging, rating, application services on internet. These services could be consumed by operators instead every one building themselves. Telecom domain is always a front runner at concept level. Hub & Spoke model of Telecom switches was innovated three decades back. This model is foundation for buzzword ESB nowadays.

Integrity of Bloggers

Few months back, there was lot of buzz around the Blogger's Code of Conduct from O'Reilly Radar. My viewpoint is that blog shows the level of Blogger integrity. My thoughts about Employers and Employees perspectives are -

Employers Perspective - Many companies are not in favour of employees expressing views in public domain. If you see from employers viewpoints, not all employees are mature and have high level of integrity. There are intermittent periods when employee is not satisfied due to any reason and publish their views based on perception or prejudice not on facts. Blogging requires high degree of mutual trust between employers and employees.

Employee Perspective - A blogging demands a high integrity from the bloggers. In my view, best practice is to keep blog independent of company references. Never ever share the company information or link to company site. Blog's objective is to share your thoughts with people with same frequency. There is no inherent requirement to share any kind of company information.

Few attributes of good bloggers -
1. Ownership - Any comments published on one's blog are responsibility of blogger. Always keep moderation on for your blog. Just publishing a disclaimer is not enough.

2. True Character -Its a test of one character when things are not moving in right direction in professional life, one should resist any comments on it. This is time when you will do something unethical. If you can't resist and can't stop yourself from mud slugging, stop blogging for sometime.

3. Correct information - Bloggers shall share the correct information. It should not be biased based on one's goals. This shared information is for the benefit of bloggers community. This is platform which provides the opportunity to learn from each other experiences. May be good idea is to declare one's level of expertise on blog topic.

4. Respect - Show respect for other bloggers. Only constructive comments drives the fruitful discussion.

Happy Blogging !!

SOAtization of Enterprise Culture

For last few years, whenever any projects is initiated or any product is launched, it claims to be following principles of SOA. Most of big Enterprise claims that they are in process of successfully adopting SOA. To measure the maturity, one can find many SOA maturity models on lines of CMMi models.

Actually, SOAtization of Enterprise is a change in culture of Enterprise. One needs lots of impact players, support of management, proper communication to developer community, strong collaboration with business and Enterprise Architecture team.

SOA is a concept, architecture approach and above all its a cultural change. Enterprise starts discussing in taxonomy of business processes. Top down approach is followed to find business services. Delivery teams believes in building reusable business services and infrastructure services. A proper governance exists and services are registered in repository. People don't owns the applications and projects.

Simple way to check the SOAtization of the Enterprise is to find whether people are building business processes or applications.

SOA - The Elephant

There is always a debate who should drive the SOA initiative in Enterprise. It could be business, architecture team, delivery or Operations team. It benefits all of them in different ways. SOA from different viewpoints looks like
- Business see SOA as a set of business services that are exposed to its clients. It reduces the time to market and costs of building business processes. It increases business agility and simplify the IT.
- Architects see SOA as an architectural approach to build business processes. It is based on well known principles and patterns like loose coupling, separation of concerns, encapsulation etc. It constitutes of provider, consumer and contract.
-Developer see SOA as a set of standards, tools and technologies like Web Services.
-Operational people see SOA as a better contract between Service provider and Service consumer.

In my view, SOA impacts the entire Enterprise and everyone is stakeholder. Unlike earlier concepts of distributed computing in IT, SOA is more near to business people. Hope IT will fulfill the agility and reusability promise this time.

"Meet the Architects" Video from Youtube

Meet the Architects
http://www.youtube.com/watch?v=Df4RnVl03Es&mode=related&search=

"The World is Flat" by Thomas L.Friedman

Shape of world is changing from Round to Flat. This brilliant book finds out the forces behind it and impact of them on our day to day life.

A must read book for every organization & individuals who wants to survive in Flat world. Rules of game are changing. Countries & Corporation who will adapt to changing rules will grow and others will fight for their survival.

I feel, in another decade, people in India & China will face the same challenge and difficult time as faced by people in West today. It will be opportunity and concern at the same time.

Another thought, all flatteners are happening to reduce TIME spent in chores. Time is becoming most precious and whatever we think of today is time consuming, will not be done by us in future. It will be either outsourced, off shored, in-sourced, automated, extinct or ignored.

Check Convergence II chapter in book, vertical silos are replaced by Service ecosystem in businesses. It reflects that World is also adopting concept SOA in its own way.

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?

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?

Attended Agile session

Today, I attended excellent Agile session conducted by NCR Agile User Group (NAUG). It was well received and lot of good discussion happened around Scrum & XP.

There were people from different companies. They are using different processes and methodologies in their respective projects. It was nice experince to listen different views.

Few discussion points were
Pair programming - It was hard to convince about Pair Programming productivity. Pair programming creates impression of more effort in comparison to traditional way of software development. It is true if one consider only a single sprint. But it would not hold true for complete project lifecycle. It reduces effort due to better quality output of pair programming.

Duration of Sprint - Good discussion happened on duration of Sprint. Scrum recommends almost fixed 4 weeks sprints with daily scrum meeting.

Rework or Refactor - A new name to rework in Agile is refactor. Is it possible to avoid this in traditional methodology? Refactor is going to survive and will promote Test Driven Development along with it.

One of major practice of Agile methodology is continuous feedback from Customer. It may be difficult to find customer who wants to work in such close collaboration mode as required by Agile.

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.

Embracing Agilism

My view on How come Enterprise Architects don't embrace agilism?

Two ways to adopt the change in corporate world, bottom up or top down. Bottom up approach means someone unknown in enterprise adopt a new tactics to improve the conventional procedure. It is adopted by small project and benefits are published at enterprise level. In this case, change is accepted slowly or sometimes never.

Secondly, in top down approach, management decide to change the things for better and publish new guidelines to be followed by corporate. Change is easily accepted in this approach. But no one in top wants to take risk which comes packaged with change.

In both the approach one needs a leadership quality to spread the benefits of change. Take a case of Agile methodology, its like a change.

Agile is gaining momentum. Corporate are trying its best practices like Test Driven Development etc. Mostly, its happening through bottom up approach. A slow approach. It is not easy to change the whole process in one go. Big Enterprises are embracing agilism in bits and pieces to find the benefits.

First impression of SOA on Business user

Is Business user ready to accept delay in response? Is it matter to Business user whether the services consumed runs on old legacy architecture or hyped SOA architecture? What all matters to Business user is usability? Any upgradation in technology should improve the functionality and quality attributes. First step towards SOA impacts performance. Decoupling of components/services with help of XML creates overhead in terms of XML processing, transformation and routing of messages. All these steps eats up significant processing time of request.

First step towards SOA doesn't create positive impression on business user. It becomes difficult to sell SOA to business stakeholders. Short term hurdles stops adoption of long term benefits of SOA.

SOA looks quite similar to Remote Entity bean concept in EJB 1.0. Conceptually, both are suitable for ideal scenarios. They attract purist who wants to follow the architect principles without business value. One may say Entity beans were fine grained domain objects and SOA are business services. Session beans orchestrate entity beans, similarly BPM orchestrate business services. Does any thing like local interfaces concept will emerge in SOA world?

SOA makes sense in case of B2B and services which are exposed to external clients. But within scope of Enterprise, do we want to consume slow business services. Its a call between performance vs flexibility. Lets see who wins or we are able to find the win win situation in time.

Long term vision vs Short term goal

Sometimes, there exists a conflict between Long term vision and short term goal. To achieve short term goal, project team compromises with Long term vision of product/program. It looks most practical to divert from the correct path and take short cut to deliver.

Occasionally, project team wants to ignore the long term vision in order to mitigate the impact on short term goal. Project Management and Business requires solutions as early as possible. Over here, it becomes responsibility of architecture team to explain , convince, mentor, motivate, communicate, enforce and sell the correct path and produce standards & guidelines for the benefits of project in long term. It helps stakeholders to take informed decision.

A mature and motivated IT team keeps moving on correct path to achieve the Long term vision. IT team always needs support from the management and business stakeholders. Does this holds true for Enterprise SOA ?

What can happen to IT Ecosystem w/o EA ?

Sometimes picture depicts more than hundreds of words

Few thoughts on Ruby

I took sometime to write this small blog. Blogs from James McGovern raised my curiosity on Ruby. I wanted to make my hand little bit dirty before writing.

Basic principles of RoR
1) Don’t repeat yourself (DRY)
2) Convention over configuration
3) Instant deploy
4) Ease of learning and more pragmatic
5) Built-in reusable components like ActiveRecord, ActionMailer, ActionPack, Action WebService

It is made for small to medium size application development. It is based on existing best practices in J2EE and DotNet world. It hard codes all best practices and makes them principles. No easier way to improve or change them. I feel with time best practices will improve and Ruby won’t be able to incoporate all of them.

It’s an interpreted scripting language and people from background of Python, Pearl and PHP will feel happy to move to object oriented scripting language.

My experience is in early stages of development Ruby increases the productivity but as application grows it starts taking time equivalent to or more than other Web frameworks. Ruby has its own boundaries and constraint which bounds the new developers to follow the convention and shows the best direction. But anything outside the boundary of Ruby will become difficult to implement. Inexperienced developers would make less design errors while working with Ruby in comparison to J2EE.

Currently it satisfies needs of small to medium projects with small team. May be in near future enterprises will start adopting Ruby for internal applications. It suits web based application on simple CRUD requirements without any need for complex business logic, sessions, security, availability, clustering and transactions. Let Ruby be like that.

In future, Ruby community can keep adding baggage in Ruby to fit all kinds of projects. But I feel it will act like a slow poison for Ruby simplicity. There is lot of scope and lot of small projects which will go for Ruby in future due to simplicity. But if Ruby community tries to make every customer happy with inclusion of all unbaked features, it won’t take Ruby to home.

I suggest for next 3-5 years, fix the scope of business requirements which Ruby will cater and sell it. Instead of expanding to everyone needs. Focus on niche small to medium web based internal application development. It will increase visibility of Ruby and it will also increase the number of people who knows Ruby well.

Way Forward in 2007

I am not the right person to predict the way forward in 2007. During last quarter, I got little time to go through buzzwords. Hope, I will find some way to reduce meetings in this year.

I hope that Architect's world and I will understand the basic principles better in 2007 and onwards -

1) Loose coupling and Reuse - Will adopt SOA to push loose coupling and reuse.

2) Abstraction - Add more XML files to abstract things.

3) Layered architecture – Vertical silos will break to give way to horizontal layered architecture in different domains.

4) Segregation of concerns - Cross cutting open sources like Acegi will gain momentum.

5) Cohesion - More companies will consolidate/merge to make impact especially small companies working in niche areas.

6) DRY - Move from code reuse to component reuse to service reuse.

7) Add more indirections - More virtualizations at different layers like Data and Servers.

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 ;)