Where People Live? And how to help them decide?

I have been thinking about how people decide where to live. In some ways, as affluence is increasing, people have become more selective about where they live. I am not sure, if the traditional factors of commute time is the only factor people use today, as was the thinking till a decade ago.

Somebody mentioned a statistic that I was surprised to hear. It said that today 70% of white collar work happens in non co-located teams. Which means people no longer work with people in the next cubicle or down the hall. This also means that people are no longer chained to their desks.

This has meant that there is more flexibility in where people choose to live and it is no longer tightly coupled with where they work. Families with kids ofcourse focus on living next to schools and neighbourhoods that are safe and good for the kids. Families with no kids, which are an increasing number year over year, locate based on their non-work related pastimes. Such people locate near theatre and art districts, outdoor getaways and urban parks.

An interesting book I read a little while ago was Who's Your City?: How the Creative Economy Is Making Where to Live the Most Important Decision of Your Life where the author actually describes how these decisions are being made by people of different walks and in fact the criteria is changing on a day to day basis.

All this factors into how real estate companies need to allow home buyers and renters to find properties online. It should allow people to select what is important to them in terms of walking distance to cultural centres, schools with a certain rating, neighbourhood safety and so on, and finally average commute time to the work place.

The Architecture of Integration - Part 2

Many months ago, I had mused on developing a new architecture of integration. Unlike the old models, whose focus was simply on ensuring connectivity and transfer of information from one context to another, in the new model, the focus was more on an expanded context that assimilates and re-formulates the information.

How should one go about it? To start with, I think the context can be re-formulated as the mental model the user has. Each user has a different mental model, and instead of trying to force fit the software's mental model to the user, I think the user should define the mental model as part of the profile.

So, lets say, I, user A, am someone who likes looking at numbers associated with a news feed or a task list. So, if I am reading a piece of news on robbery, I can access information by hovering over a word on number of robberies near where I live, or number of robberies in this area over time, or any other statistical measure associated with it. I may want to get details on robbery prevention program in my area.

Another scenario could be, someone sent me an email asking for approval to buy new laptops for the department along with specs. I could look at the model selected and be presented with information on its approval rating at amazon, and other retailers, recommendation on the CPU, known failure rates and information on if better processors are due in 2 months and I should hold back on the purchase.

The same email containing identical set of specs if sent to the support team would present a completely different set of information, such as if the monitors will need to be hdmi enabled, or if they need to buy DVI-HDMI converters. The finance department, on the other hand would be able to determine the budget approval tied to this purchase and procurement would know if tendering rules were followed for procurement. 

To achieve this, I think, what is needed is that each user's context needs to be tied to their enterprise profile. This way the "Context Mapper" only needs to know that it needs to embellish the information presented with new information. Each system does not need to know how to parse each information and which system to go to fetch additional information. Also, the information is fetched at runtime so the container software does not need to know anything about me except my unique identity. Users can manage their profiles in an organization as their perspectives change from technical to more general management, and they are able to interpret new perspectives and are willing to unlearn other ones.

Taken in other contexts, this can be extended to many application domains where the same raw information needs to be presented in different ways to different people for it to make sense out of it.

If only, this could now be extended to facebook, where I could know "Like" balance sheet with my friends when I post my "Likes".

The Architecture of integration - Part 1

The architecture of integration

Increasingly I am finding myself involved in Integration projects. Now for a moment, I do not doubt that many people have solved the problem before me. However, I am not sure, I can completely agree that the way it had been done before has completely solved the problem.

The new definition of the problem

To me, now the problem is fundamentally different from the way it has been theorized before. The older interpretation of the the problem has been about connectivity. About one system, user sending an element of data or a message to another department or system.

However, people now see the problem differently. Any business now has multiple views. The operational view, the management view, the financial view, the project view, the process view and so on. There are new views being added to the whole game. There is the regulatory view, the performance view, the strategic view, the spatial view, and so on.

Each of these views adds new contexts to the problem domain, abstracts and reveals new details, and in many cases serves the need of specific stakeholders. In many cases, the view is for a specific stakeholder department and may serve the needs of that specific entity.

The old paradigm of integration is just one trying to see the problem from one view

In the past, integration paradigms focused on a process view alone. So if purchasing makes a request for an order to be filled, when the account is filled, the payment, inventory and purchasing systems should be notified our updated. This started as point to point integration between different systems.

This lead to the problem of a spaghetti of connections. The hub and spoke model was a way to centralize all connections to a single hub. The hub and spoke integration architecture eventually evolved into the enterprise service bus architecture with its decoupled interfaces for business applications. However, these integrated views do not belong in these models.

The word integration appears because of people's ability to conceptually understand a content management system as being different from an enterprise resource planning system which is different from an enterprise asset management system. This is no different from people understanding a hospital as being different from a college being different from a library. However, in the modern city or even a rural city, a single facility may provide the roles of a medical college, a hospital, as well as a specialized library for students and doctors.

I'm trying to articulate the new integration paradigm. There is thus an opportunity to list all the business functions and figure out a combined program. Depending on the context some functions may actually belong as an integrated whole where as others may continue to be separate envelopes that are connected via interconnections.

The architectural problem then becomes which business functions sit within the same envelope and which functions get their own separate envelopes. This is the subject of my next post .....

Bespoke versus mass architecture

I am now in the process of debating a new item of concern - Be-spoke versus mass architecture. Essentially, for an architect, there are two ends of the problem space. At one end, there are problems and markets that need a mass solution. Ability to scale and reach are the most important problems that need to be addressed. At the other end of the problem space is bespoke or custom architecture. Here you work with a specific client and create a solution that is ideal for them. This is potentially a smaller size of market in terms of potential revenue, but do I really care?

Increasingly, I see that I get paid X amount of money per unit of time I spend on a specific problem. I am no genius and developing an optimum solution needs time, patience and focus. Ultimately, I find that I can do all the analysis I want, but a coherent solution "comes" to me when I have no more questions to ask. It creates itself, when I am ready to receive it. When I rush, and hop between competing priorities, I need to resort to brute force to come up with the solution.

Since my rewards are tied directly to the time spent by me, I will never earn multi-pliers on a solution. That is for my employer. My employer, of course wants to make tons of money. To do that he has to pay me, and the rest of the organization to deliver on the conceived design.

This is where things get tricky. Should I, as the architect, worry about the marketing potential of a design and how I could generalize it to serve as many customer segments as possible, or should I stick to the brief I have been handed? Am I qualified to assess the potential of a product, or should I stick to my design mandate and let the risk takers decide how to position the end-product?

Another question is more personal. Do I want to be the architect of a product that sold millions of copies or do I want to be the architect of the product that solved person X/ company Y's problem?

And finally, what is the direction of growth I am seeking? Something that can scale up and solve a small problem for millions of people or scale up to handle more complexity and comprehensiveness for a single customer?

This is a longer debate, and one that will  need more thought for me to be comfortable where I am and the path I have chosen?