Category: Softwares

There comes a time in our career as an architect when we realize many of the issues we encounter are recurring. Though the project and industry may change, many of the problems are similar. At this point we can draw on our experience to provide many solutions quickly, leaving more time to enjoy the challenging issues. We‘re confident in our solutions and we deliver as advertised. We have reached homeostasis. This is the perfect time to make a colossal mistake – like deciding you know so much that it‘s time for you to start talking more than you listen. This poor decision usually comes with a side of cynicism, impatience and general anger towards inferior minds who dare contradict your superior understanding of all things technical and otherwise.

In it‘s worst form this overconfidence bleeds into the business realm. This is an excellent way to land your career on a list somewhere next to the Black Rhino. The business is our reason for existence. That statement probably hurts a little but we must not lose sight of that fact. We live to serve them, not vice-versa. Listening to and understanding the business that employs us to solve problems is the most critical skill we possess. Ever caught yourself impatiently waiting for a business analyst to finish talking so you could make your point? Chances are you didn‘t get theirs. Show the business domain experts the respect you expect to receive, this is the last group of people you want viewing you as unapproachable. If they start avoiding you, you‘re being a catalyst for communication breakdown and sabotaging your own project. Remember; when you‘re talking you can only hear something you already know. Don‘t ever start thinking you‘re so smart that no one else has something valuable to say.

When we are listening we‘ll often disagree with what we hear about how the business operates. That‘s fine. We can make suggestions for improvement and should definitely do so. However, if at the end of the day you disagree with how the business is run and it’s not going to change, that‘s just too bad. Don‘t allow yourself to become a disgruntled genius that spends all of your time trying to impress others by making witty, condescending statements about how poorly the company is run. They won‘t be impressed. They‘ve met that guy before and they don‘t really like him. One of the key ingredients to the recipe for a great architect is passion for your work but you don‘t want too much passion of the angry variety. Learn to accept disagreements and move on. If the differences are too great and you find yourself continually at odds with the business, find a company that‘s easier for you to get behind and design solutions for them. Regardless of how, find a way to establish a good relationship with the business and don’t let your ego damage it. It will make you happier and more productive.

I have seen my fair share of initiatives focus endlessly on requirements, design, development, security & maintenance but not on the actual point of the system – the data. This is especially true in content-based systems in which the data is information delivered as unstructured or semi-structured content. Great content means the difference between a system that is hollow and one that is relevant.

Content is king. Content is the network. Content is theinterface. In an increasingly interconnected world, content quality is rapidly becoming the difference between success and failure. FaceBook vs. Orkut /Google vs. Cuil / NetFlix vs. BlockbusterOnline…. the list is endless where battles have been won and lost on the content battlefield. One could argue that content-related aspects are not the software architect’s problem – but I think the next decade will certainly disprove that.

Part of the design process for a new system should be devoted assessing content inventory. Designing an effective domain/object/data model is not enough.

Analyze all available content and assess its value on the following criteria:

• Is there enough content available? If not, how do we attain critical mass?
• Is the content fresh enough? If not, how do we improve delivery rates?
• Have all possible content channels been explored? RSS feeds, Email, Paper Forms are all channels.
• Are there effective input streams built to facilitate the continual delivery of this content into the system? It’s one thing to identify valuable content, but another thing altogether to harvest it regularly.

Make no mistake, the success of a system depends on its content. Spend a healthy part of the design process to assess the value of your content. If your findings are less than satisfactory then that’s a red flag and the stakeholders must be advised about. I have seen many systems that fulfill all contractual obligations, meet every requirement and still fail because this fairly obvious aspect was ignored. Great content creates great systems.