Got home early last week and was down in the park with my kids and a couple of dozen of their friends (monkeys all of them but of the human type). It was a nice summer evening, the sun was doing its bit and so was the breeze when the monkey troop came back into the complex. They normally stick to the outside of the complex but chose to come right into the heart of it that day, no doubt attracted by their human brethren.

The effect on the kids was remarkable, the impact on their parents – mostly mothers and grandparents, I guess I was the only father on show – was even more. Monkey seems to be one word in the vocabulary of all kids of all ages from 8 month old toddlers to 14 year olds.

Mon-gey, mon-gey went little Tom from Kerala jumping around excitedly, “Uncle, uncle many monkey, many many, monkeys sisteen monkeys” lisped another fellow whose name I don’t know.

All of us were watching the monkeys quite enjoying ourselves, the little boys who are quite berserk in their normal state went ape and started destroying the foliage in the garden with renewed vigor in their attempts to climb the trees around our little park.

“Nuisance!!” said a cultured voice next to me, looking at the little boys I nodded my head in agreement. It was lady A, a rather aristocratic person with kids the same age as mine who tended to set rather high standards for everything and consequently held almost everything in disapproval.

“I meant the monkeys” she continued. “ Ah!” said I guiltily, lest she think I disagreed with her. Just then one of the monkeys dropped a pigeon egg to the ground. Our complex has more than its fair share of pigeons – they spend the day cooing, strutting around busily, spreading vast quantities of dropping on the floor of the complex and taking to flight in panicked hordes at periodic intervals. Harmless beasts in my opinion, besides my daughter loves them just as she loves all animals.

“They are a nuisance too” continues Lady A, “ the society committee must drive them away, dirtying the whole place”. I interpreted this as the pigeons who were dirtying the place and not the members of our committee a rather aged bunch who by no means could chase away a few million pigeons and did not feel the need to do so either.

“ and they must chase away that cuckoo too” she continued “ silly thing, waking us all up early in the morning with its cries”. Now that was going too far. I am personally acquainted with said cuckoo – a slightly demented fellow who gets very passionate about his lady love at around 5:00 AM and holds forth in melodic expression. Many a time I have woken to the cry of the cuckoo and gone out for a walk with my dog. If you walk into a Bangalore morning at that time with a cool breeze blowing and the dawn just beginning to turn the sky a delicate shade of pink I bet you would sing out too – provided you are in love of course.

I sidled away from Lady A’s disapproval as elegantly as I could. Did not want to hear what she would damn next. But this got me thinking, many of us are like Lady A, we have so little patience for the creatures around us, so little sympathy and appreciation. I saw a sparrow in the airport the other day, thrilled me to bits but to most people it is “how do I chase that blighter away before he drops excreta on to my fancy clothes”.

Have a care my friends, have some tolerance for our fellow creatures, a sparrow is already a seldom seen sight – soon cuckoos, crows and pigeons will become rarities too. Then what, we transfer our intolerance to our fellow people – wait but we have already done that!!

There has been a fundamental shift in human society over the last couple of decades that has touched and impacted all of us. Access to information, automation and global communication has, to borrow a phrase – made “geography” history. We live today in a world where computing is taken for granted, where it is becoming increasingly difficult (and unnecessary) to tell the difference between a cell phone and a personal workstation. The average young person today, who incidentally is the target customer for the products and services offered by several competing enterprises, is completely comfortable with the notion of an online existence and with services and products delivered online. This young person is not just comfortable but is extremely knowledgeable, very demanding of quality of service and has very little patience before switching to a better set of options. This young person is now an integral part of the existence of many enterprises. Her tastes and expectations have a significant impact on the development of enterprise application systems. Paralleling the evolution of this young person has been the evolution of the internet itself. The net 2.0 and 3.0 as some people refer to it is all about collaboration. The net has progressed from an information dissemination mechanism, to a viable commerce mechanism to now being truly a collaborative network that brings people and organizations together. Collaborative services are where the true power of the net lies. The same evolution is also happening within the business strategies of enterprises. Collaborate to compete is the mantra and the provision and consumption of services is the environment businesses live in. An interesting description of the service oriented economy is the statement that businesses are comfortable using services provided by resources they neither own nor control.

This shift in market and social dynamics has had a significant impact on the nature of enterprise information systems and how they are developed today. The fundamental changes that are happening include:

1. Software today is business critical – Automation, centralization of critical information and enterprise application integration have created environments where manual processing of information has been almost completely eliminated. While this has brought great efficiency to the enterprise – the dependence on enterprise systems to process information is total.
2. Enterprise information systems are not built and operated in silos any more. Integration between applications across business functions is almost a necessity.
3. For several enterprises whose products are services such as banks and insurance companies, the notion of fixed and silo products is disappearing. Products are built and rebuilt all the time by repurposing a set of underlying services and functions
4. Software systems are often the direct interface to the business’s customers and stakeholders. Unlike the earlier days of terminal and back office processing where the customer was separated from the IT systems of an enterprise by an effective wall of human interaction, the customer today is a key user of many enterprise IT systems.
5. The distinction between classes of systems such as content management, transactional and analytical systems is vanishing in the eyes of the user. The same user often uses all three and expects consistency across the systems
6. Increasing software complexity – every generation of software is functionally more complex and has a richer set of features. Every set caters to a larger and wider span of audience with a more diverse set of needs.
7. The growing importance of standards – the business, operational and political environment in which software is used today mandates compliance with a plethora of standards such as SOX and BASEL2. Adherence to a standard is often not an option for businesses today.
8. The growing cost of software and the increasing pressure to reel this in – software systems today have astronomical Total Cost of Ownership figures. Organizations are adopting multiple strategies to bring these costs down including global outsourcing of maintenance and management, centralization of systems, leveraging pay-per-use and hosted service models and increasing adoption of open source technologies
9. The management of enterprise systems is no longer considered to be something that must be retained within the enterprise. Outsourcing the management and delivery of the service to managed service providers is the preferred option. Enterprise applications are today expected to be built to integrate with larger enterprise management contexts
10. The service oriented universe – enterprise systems are not built as isolated silos any more. Well defined service interfaces form the basis of their integration and interoperability and make them essential to every part of the business. Expectations of quality of service of enterprise systems are significantly high. The cost of unavailability or degraded service is in direct monetary terms and of significant business impact
11. Maturing of open sources – the success of open source technologies such as Linux and the JBOSS application server coupled with innovative licensing models and lower cost of ownership has led to a significant acceptance of open source within enterprises. The collaborative development approach and sourcing of specific components from small vendors and the open source environment is the way to go in many enterprises
12. Pressure to reduce the software development times – software is moving from development to configuration. The expected time to deploy a new software system has gone down from 2 years to nine months to 3 months over the last few years.
13. Pressure to adopt methodologies such as agile development – the success of agile development methodologies and collaborative, iterative development is accepted and is becoming increasingly the approach development teams adopt. The biggest challenge teams face is integrating these methods into the context of overall organization level processes such as CMM and ISO
14. The growth of enterprise architecture as a strategic part of an enterprise’s business strategy – for several enterprises whose products are services such as banks and insurance companies, the notion of fixed and silo products is disappearing. Products are built and rebuilt all the time by repurposing a set of underlying services and functions. The need for a common enterprise architecture across these services and the way they are used is critical and enterprises are increasingly investing in developing such architectures
15. Developer turnover, rapid promotions and astronomical growth – software development is an increasingly competitive and expensive venture. Small companies I meet often describe themselves as training grounds for fresh developers who spend a couple of years gathering skills and experience and then move into the race for higher pay by jumping to larger and multi-national development organizations. 2 years seems to be the magic number for stability in this space – after which the itch to switch kicks in. To combat this organizations adopt multiple strategies including astronomical salary growth (the % increase in Indian salaries this year is amongst the highest in the world) and bizarre promotions quite out of perspective with number of years of experience (entry level developer for 2 years, senior developer for another 2 years, tech lead for 2 more, manager and senior manager in another 4 and president of the country in 24 years?) Then there is the issue of growth in software organizations – you have around 10 to 15 thousand new employees joining one of the larger services organizations every year – imagine the challenge of settling them in and getting them to be productive parts of teams
16. Increasing salaries vis-à-vis decreasing cost of production – the fact that the cost of ownership of software is already out of proportion is well known and there is a universal push to rein this in. Development teams in this space face the significant issue of trying to balance increasing salary and operating costs against the pressure from their customers to deliver more complex software at lower costs

So what do these changes imply?

1. Architecture and design are super-complex requiring a team of super specialists. Take for example the architecture of the virtual university that I am currently working on, we need expertise on distributed application design, large scale data modeling, semantic networks, interaction techniques and learning management, multi-media technologies in the context of virtual classrooms, networking expertise, interfaces with broadcast media, standards such as SCORM, setting up collaboration systems and many more.
2. Architecture and design needs more than technology skills – systems thinking, problem solving, abstraction and generalization, communication using different languages to different stakeholders, integration skills and not the least project planning skills are all equally important.
3. There is an increasing need to move away from single system engineering to the development of platforms that evolve over time using progressive improvements in functionality are offered to users.
4. The productivity challenge of building more complex teams with cheaper resources at a faster pace is severe – several approaches are practiced including COTS, reusability, agile programming and so on. These approaches in turn add to the quality engineering problem of building systems whose stability and performance can be assured.
5. For a long time now, design Gurus have been advocating simplicity as one of the key factors to the stability and quality of a system. The environment is not going to get simpler – nor are the challenges of development going away. Simplicity has to be arrived at through conscious effort to improve engineering quality
6. Simplification of the development universe for a development team has in itself to be considered as a design problem and solutions such as those based on product lines and platform oriented development have to be engineered and invested into
7. NFRs should probably be renamed as Important Stability Requirements – somehow I have a sneaky feeling that by calling requirements that specify the stability, performance and such characteristics of a system Non Functional Requirements, we have done systems a big disservice. It seems to me that the “Functional” part is often silent and we read this as “Non Requirements” either consciously or unconsciously. Why else do we ignore these for the most part in our design and deal with them only at the end of a project after we have built most of the functionality? The stability of a system that needs to operate with the challenges I listed earlier is as important if not even more so than the functionality it provides. I propose that we start thinking of NFRs as Important Stability Requirements – change the name, drop the “NON” and see the difference it makes
8. Manageability is a the new key ISR – performance, availability and even reliability have traditionally been stated and defined as expectations of stability of a system. The critical addition to these in today’s business environment is manageability. Manageability is the index of what is built into an application to be able to guarantee that it will operate in its environment with predictable quality of service

So what?

Life is tough for organizations developing software to be used in the enterprise space. They face pressure on all fronts – what they need to build is more complex, the knowledge they need is more intense and specialized, they face severe resource pressures and are driven to improve efficiency of production and the effectiveness of what is produced. There are not many magic bullets available – there are however some medicines that one may try but these call for patience and a little investment into engineering that is not in the context of what is required for a project. Will these organizations avail of these medicines – your guess is as good as mine, but I do believe that most of them will.
Mañana las medicinas. Some mañana that is

Russell Ackoff describes synthesis and analysis as ways of thinking. Both involve three steps:

• In analysis, something that we want to understand is first taken apart. For instance we could take an ERP system that we are defining into modules for material management, production control, finance management and so on. On the other hand, in synthesis, that which we want to understand is first identified as a part of a larger system. The ERP system is a part of a larger system – say the manufacturing organization that needs to use it to manage its operations and resources
• The second step of analysis is to make an effort to understand the behavior of each part taken separately. In synthesis, an effort is made to understand the function of the larger system of which the system we are working with is a part. So we would as part of analysis look at each module independently but as part of synthesis understand the functions of the manufacturing organization
• The third step of analysis is to aggregate the understanding of the parts of the system in an effort to explain the behavior of the whole. In synthesis, the understanding of the larger containing system is disaggregated to identify the role or function of the system to be understood.

This gives us an extremely important insight – analysis of a system reveals its structure and how it works. It does not give us an understanding of what it is expected to do – its behavior and function – as part of the larger system that it belongs to. This understanding can come only from synthesis.

Most often, when we start defining the requirements of a software system, we lose the “system” perspective and think about only the software application being built. In my experience, this is a sure fire method of missing out on vital aspects of the applications quality. The synthesis exercise puts the application we are building right there as a part of a bigger system thus ensuring the systems viewpoint is not lost. This viewpoint is so extremely critical because the supportability needs of the application we are building is provided via this viewpoint. Synthesis provides a more complete perspective about the following:

• Users, usage patterns and expectations – A typical analysis exercise brings the users who interact with the application as part of its operations into focus. So if we were building a system for inventory control, our focus would be on the inventory managers and the operators within a warehouse. The synthesis exercise however tells us that this piece of software is part of several other eco-systems – for instance a datacenter in which it is hosted, a part of a larger supply chain management system, a critical element of business planning functions and so on. It also brings out several other nuances such as the system needs to be maintained and upgraded over time; it needs to be audited as part of the larger financial accounting process; while the inventory managers and warehouses work on a 9 to 6 basis, the ecommerce system queries it and blocks inventory on a 24×7 basis and so on. While the more “business” needs do get addressed in most requirements, the subtler ones specific to management, auditing etc often get missed out and are bolted on later.
• The overall operational context – the other systems that this is a part of brings out specific needs of integration as well as expectations of performance, reliability and stability. In fact as more and more business processes are “composed” on top of a set of applications, the silos between applications are rapidly breaking down. Viewed at from the process perspective there is an underlying fabric of application services that can be composed to create a business process. Building applications that are part of this fabric without taking into account the needs of the fabric as a whole is I presume an evidently bad idea
• The timeline and lifecycle of the application – moment the application is considered as a part of a larger system, decisions on the lifecycle of the application – when can it be put into production, turned off for maintenance or replaced with the next version of the application get pushed up because of a larger set of dependencies. The criticality of an application can only be gauged in the context of the larger system it belongs to. Understanding this perspective and how the larger environment is impacted by the lifecycle of the application is a key input to design. Synthesis also brings out the view that a good part of the application’s life has got software developers as the primary users of the application, either in development or maintenance mode. When was the last time we thought of building tools, code snippets or even documentation for our fellow developers from this perspective?
• The standards the application is expected to adhere to. Information systems are increasingly forced to adhere to a larger set of standards and regulations ranging from IT policies, security standards, operational procedures, compliance and control procedures and so on. I have gone through the rather embarrassing experience of having to pull a software system back into development from the verge of going into production because “no one ever told me” that the IT standards demanded automated installation with a complete audit trail of every change made to the application – “you mean you never read the IT standards manual?”
• Synthesis also allows you to define crisper definitions of SLA commitments your application must keep. Rather than arriving at arbitrary numbers for say the response time of a query or the size of records to return understanding the context in which the query is used and the performance demands from that context serve as more concrete guideline. It is a fact that SLA definitions are moving from being bottoms-up to being top-down. SLAs are now being defined at the level of business services and are flowing downwards to the other parts of the system that render this service. The storage requirements for an encrypted auditing system you are building for a bank could well be defined by a BASEL-II definition implemented by the bank that states that all customer information must be stored in an unmodifiable format for say 6 years. If the bank states that its processes and services are BASEL-II compliant, then sure enough your storage SLA has just got defined.

It may seem to many of us that these perspectives got from synthesis would be uncovered as a part of requirements analysis in any case or even that this is information that we would get from users or business analysts. However this view is not true. Users or business analysts focus on specific aspects of the application and its functionality and have very seldom any idea about its operational context. Further, once you get into the analysis mode – you have started drilling down into the parts of your application, you are lost in entities, attributes, relationships and events. As part of this process, you are not going to encounter the rest of the system that this is a part of. Synthesis hence must be a conscious part of requirements definition and not something you stumble on by accident. At the same time, there is often a legitimate fear of getting lost into a study of a higher system and then a still higher system and so on. What I do is to use the perspectives above to act as a guideline for me to understand the larger system. Once I have got enough answers, I move on to analyzing the requirement. I periodically take a step out from the analysis and kind of adopt a birds-eye view looking for discontinuities or a lack of harmony with my view of the larger world and then proceed with analysis if I don’t find any.

Our conversation covered many grounds. We caught up on several mutual friends and associates with whom both of us interact in different capacities. It was during this discussion that the topic of mentoring came up.

My friend is one of the most respected technologists in the Indian IT industry – specifically in the networking and system integration space. He has enjoyed a richly fulfilling professional career during the course of which he has mentored several people – I included. It was his observation that people who has risen to great heights often miss out on having a good mentor and are as a result lonely and sometimes frustrated with their jobs. My friend then pointed out that a mentor was different from a coach. Mentorship was not about the improvement of technique. A senior expert like Greg Chappel provides both coaching and mentoring to the Indian cricket team and the mentoring aspect was often overlooked when Greg Chappel is criticized for the performance of the team. Our conversation then drifted on to other topics, but left a thread in my brain that kept thinking about mentoring.

The word Mentor is derived from the ancient Greek legends of Odysseus who placed his son Telemachus in the care of an old friend Mentor. Mentor (or maybe the Goddess Athena in his guise) guided Telemachus in his times of difficulty. A mentor is a trusted friend, a teacher and a counselor. Mentorship is a developmental relationship between a mentor and his protégé.

I have been lucky through the later part of my life as a student and through my professional life to always have had good mentors. This has made a significant difference to me and who I am. The earliest person whom I can think of as a mentor was a friend of mine and a classmate in college called Manish Manchanda. I was always bright as a student (Modesty IS my middle name!) but never focused enough to appreciate studying or hard work. I remember it was at the beginning of my second year as a graduate student studying physics and mathematics that Manish one day had a discussion with me that change my life. To cut a long story short, he took me out of my day dreams, showed me a different perspective and put me back into my student world. Since then, I have had no issue with either academics, studying or hard work. I graduated at the top of my class and went on to study electronic engineering and did very well there too.

Likewise through the early stages of my professional career, I worked in Microland, an organization that captured the essence of the Silicon Valley type of technical innovation right here in Bangalore. Microland was a company where ideas – if they were bright – found a fertile growth to germinate on. Mentorship was an integral part of the organization and I remember being gently and at times not so gently being guided along.

Over the last few years, I have not had a mentor from within my organization. However I have had and still do have some of the best mentors I could hope to find. My friend Nagaraj is one, so are Samir, MSR, MLN, Anand and several others. My life is a lot richer because of them.

A mentor, to me, is a person who is first and foremost someone you can trust and have instinctive respect for. A person from whom you always have something to learn. A mentor is part teacher and part friend. Unlike a coach whose strength is analysis and consequently who works to improve your technique or to iron out your flaws, a mentor’s strength is synthesis. She (or he) provides that wide angle perspective, the ability to see you in the larger context that you are a part of and provide the necessary inputs that you could use if you so desired. Mentors don’t force you to do things. They provide choices. A mentor may be assertive and forceful at times but that is only to drive a point home. For many of us who would otherwise be lost in our daily drudge, a mentor is the person who comes as a breath of fresh air and gives us the strength and more importantly the belief to lead fulfilling lives.

I have been a mentor too and it is an experience I have enjoyed. However, in an earlier organization I worked in we had an organizational formal mentoring program where each of us senior managers was teamed with a bunch of bright sparks in the organization whom we were supposed to mentor. We had to have at least one mentoring meeting a month and had to report on progress. I could never succeed in this. I could not mentor someone with whom I did not have an established relationship of trust. Establishing this relationship was not something I could do with everyone assigned to me. I believe that there is some chemistry that must click. Something that tells Arjuna when he sees Krishna that here is my guru and the same something that tells Krishna to recognize his protégé. There is this mutual reaching out that happens and in my experience as a mentor and a protégé this reaching out cannot be manufactured.

I came away from our meeting yesterday refreshed and with a renewed sense of purpose. I do not remember discussing any problems or asking for help or even clarity. It was provided all the same. A feeling of warmth was imparted and I got a feeling that I belonged. I walked away with a clearer perspective and with unasked questions answered. Thank you my dear mentor.