Wednesday, March 27, 2013

Planting trees rather than crops

As I thought about the million things each of us has to worry about, I realized that many things that I have initiated, perhaps needs a different approach to management. I need to move to a model where things can grow on their own without needing constant supervision.

In the short term, we tend to go about initiatives that we can initiate, cultivate, grow and harvest. The problem is that there are only so many things one can handle this way. This is akin to planting crops that we need to farm and tend to everyday. The bigger problem is that once harvested, you have to start all over again. This provides quicker gratification, but you are caught in an endless cycle of planting, growing and harvesting.

In comparison, planting trees is a different model. You plant the seed, water it and give it space to flourish. The payback is not immediate but once the tree has flourished, you can reap the rewards. More importantly, they live longer and provide benefits for a much longer time.

Now the task of figuring out, which trees to plant.........

Friday, March 22, 2013

Top 3 new demands for a professional

I have been thinking about the role of a professional and how it has changed from the past and how it will continue to change in the future. This was something that I ofcourse have to think about every now and then. And, it is based on how my own role fits into the equation.

I will state these in a reverse order from the least important to the most important.

#3 : Skill is still very important
In every profession, the key difference between an amateur and a pro was and still is skill. How well to do a job is still very important and perhaps more important now. This is because, in today's world of transactional relationships, if you cannot do your job, you will not get compensated.

#2: Attribution is important.
In today's age of copy paste freedom heaven, it is important that people know who did the job. Whether it is by having your name on your work, or making sure everyone knows through word of mouth, attribution is important than ever before.

#1 Defining what needs to be done for yourself and for others.
This is perhaps the most important job. Everyone is struggling today to define their work. If you can do that not only for yourself, but also for others, that is leadership. People should be able to understand their own work based on your actions, thought processes and outputs.

Let me know what you think .....

Friday, March 15, 2013

Design Patterns Oversold

When Christopher Alexander wrote the book "A Pattern Language" in 1977, it was a part of a 2 volume series, that tried to understand the sophistication of design in everyday buildings. It was trying to capture something that had been learnt over centuries, if not millenia.

He would not have understood the passion with which software engineering discipline embraced and then took over the conversation. Today, software engineers have carried design patterns to the extreme.

Somewhere along the way the meaning or rather the semantics of the word was altered from something that had been observed, to something that is closer in meaning to a blueprint or reference architecture.

Rather than capturing the underlying structure and beauty of a solution that is perfected over time by many generations of designers, and further repeated without formal training, and handed down from practitioner to practitioner, and finally discovered and rationalized by the master; it has been substituted to mean the opposite.

Design patterns in software now means something that is created by ivory tower architects and handed down to practitioners for consumption, to prevent others from doing the unthinkable, Think for themselves.

Wednesday, March 13, 2013

Architecture of Enterprise Content Management systems

There is a variety of document management systems that are available on the market today. To develop distributed document capture and management systems needs several basic components.

1. A document capture and delivery module, which is typically an optical sensor such as a scanner or camera.

2. An optional pdf component that converts scanned documents to pdf formats.

3. An optional OCR module to convert captured graphics to searchable and extractable text

4. A job management system that can split or merge documents to a standard structure

5. A document categorization and relationship system. The categorization aspect is called taxonomy, whereas the relationship rules that build semantic knowledge is called a document ontology.

6. A business rules engine that can categorize the documents based on rules around content, logged in user, location, format, timestamp to the created document ontology.

7. An analytics engine that can track metrics and can provide capabilities for analysis.

8. A record management system for storing records such that their circulation can be controlled, authenticity verified as well as searched.

9. A workflow or business process modelling component that allows document approvals to be routed through departments or organizations.

10. An email/ electronic documents module for managing and storing emails and all sorts of digital content such as word processing documents, spreadsheets, media files and others such that they can be stored, searched, archived and accessed from multiple environments.

Thursday, March 7, 2013

The new software


Just like people can look at most buildings and estimate the decade/century of construction, so it is with software.

Any software is written based on tools and technologies of that time. Software also becomes obsolete very quickly as new technologies emerge and underlying hardware capabilities or access devices and mechanisms change.

Every rewrite is thus an opportunity to make the software more elegant and more functionally coherent.

Wednesday, March 6, 2013

The endless striving


Many of us deal with specifications that are half baked, poorly thought through and some times cobbled together using buzz words and copy paste jobs. The spec writers in my opinion disrespect the institutions that entrust them with acquiring a platform, a solution or a technology.

In commercial dealings, Sales staff who get paid based on number of deals they close, rush customers and prospects into releasing these poorly articulated needs documents to move these "opportunities" along the pipeline.

How should architects react to these? is the question that comes to my mind. Should we educate the customer into understanding what they want, or should we answer the question to make sure we pass this test and get the highest marks in any formal or informal evaluation. Should we penalize the customers for making wrong choices or should we penalize the institutions that hire these executives in the poor choices they made.

My instinct had been to try and serve the institution, understand the organization, the desire behind the specification and articulate it as such. However, this has not worked consistently. The traditional sales thinking is to give the customer what they have asked for instead of what they need.

I am increasingly also seeing the reverse during execution, where delivery organizations try to do as little as possible, to maximise their margins by delivering barely enough compared to the initial ask or the need of the customer.

Increasingly the shrill demands of sales and executives to meet numbers and margins, and ever shortening timelines drowns out any meaningful protest.

However, in my humble opinion, this is a mistake. Architects are supposed to provide the voice of reason, and ability to fight these pressures is the ultimate qualification to the job.

Monday, March 4, 2013

Observations on design of software delivery organization


Off late I have been observing an interesting pattern develop in the organization I work for, in terms of organization design of the project teams. This has been going on for the past few years. I am not sure, how typical it is of other not too big software development shops or is it unique to my organization.

The constraints are this. There is a group of people (ex-developers) who want to become managers. There is another group that wants to become technical leadership. Then there are distributed development teams that are typically under five years of experience.

The challenge is that the manager group is typically made up of people not respected for their technical skills and so cannot lead or guide their teams. They in fact are not even able to counsel their teams on what skills to develop or how to solve a problem. The teams actually respect technical leaders, who themselves do not want the hassle of managing people.

So, the firm has found a convenient way. Make the developers report to managers on a day to day work assignment and rope in the technical leads during projects to guide the teams. The managers typically perform administrative functions and do not really manage or lead their teams.

Eventually, the teams become proficient, and people start leaving as one person starts receiving all the rewards, and others find greener pastures. The managers get the credit for the teams but are in fact clue less. The technical leads are slowly replaced by the new stars and they have to figure out what they want to do next. The new stars have to then decide whether to stay in the teams, become managers removed from the actual work or become technical leads without any real teams. Dead end for every one.

Sunday, March 3, 2013

Handling functional and non-functional requirements in Integrated Solutions

Most architects I know,  squirm when told by business users that X system needs to be integrated with system Y and perhaps system Z. This is because integration is such a loose word that one could drive a truck through it. Understanding the scenarios is perhaps easier in understanding the scope, feasibility and ultimately the cost.

Functional Integration Requirements should be Use Case Driven

Thus Integration between systems is primarily functional - use case driven. Once all the Use Cases or Scenarios involving the integrated components are known, architects can dig deeper and evaluate the available and required interfaces on the target system. However, it is important to consider non functional architectural drivers, specially in integration scenarios.

Non-Functional Requirements should span Primary and Integrated Components

When thinking about non-functional requirements, we need to think about the integrated solution and not just the newly developed component. This is important, since we might run into a situation where integration with a legacy system is required to serve an architectural driver in terms of availability, stability as well as recoveribility that can not be met without a system overhaul. Alternatively, Design strategies need to be considered to achieve these non-functional requirements.

Think about non-functional requirements for integration - functionally

Like all good non-functional requirements, these integration scenarios too need to be expressed in functional terms with measurable acceptance conditions to ensure these can be designed for and ultimately tested in production.