Monthly Archives: June 2013

Want to be an Architect , can’t see ahead , what to do ?

Leave a reply

RB-JumpingHurdle

This a question that pops up in the minds of most people who take the technical route instead of the managerial route or business route after having spent some years of significance in IT. This reminds one of the snake and ladders game where you are playing your cards/dice well but are eaten up due to the monster snake on the path( existing commitments to projects or routine organisational activities). In other words you are simply not able to get time to do the things that you wanted or enrich your skills to the climb the ladder and be an architect. Always bogged down by existing tasks and they do not seem to break free instead keep adding up letting you loose grip of things. Most often we have people saying I need to get into that role because it is more challenging as opposed to what I am doing current. Grass on the other side looks green and shiny each job has its own issues and challenges. The way to work towards a career in architecture would be join linkedin groups focused towards architecture. These days there are many right from data architecture,cloud architecture,enterprise architecture,software architecture,security architecture and so on. Just as you would have made a choice of on your electives in your college stick to one and then pursue it. Drop by blogs , research papers, developers networks, communities, forums and join people who breath the same air.

There are tons of free videos on youtube on this topic and more goggling will get you better focus on what suits you and your existing skill sets. Most often get asked the question in some workshops ,by participants that “I want to be an Architect but my current job has not enough provision to extend my capabilities. Here is some quick things that you could do on that front.

Create your destiny :

Hack1 : Volunteer for activities outside of your work that get recognized as architectural in nature. Fixing analyzing issues, adding a new skill to your tech skill , participating in code reviews, design reviews and demonstrating that you just not know your pieces well but do understand the whole pieces and how they stick together.

Hack2 : Participate in showcasing your skills such as presenting or giving a tech talk at an event internal or external. Get people to listen to you using such forums.

Hack3 : Follow them on twitter , linkedin stalk them 🙂 . Read what they have to say and how they evolved from developers to their current state. Many will have a of them have funny sides and you can find yourself in those positions as well.

Hack4 : Attend boot camps, developer summits workshops which give you an outside the arena view of things in your topic of interest. Gradually incrementally add little by little to that body of knowledge.

Hack5: Think you have already become one and act like one. Fake it till you make it. You may not have genuine goodness in you but they say initially fake it till it becomes a part of your being.

To be good at something you need to follow the famous principle along with the above hacks “To master something, you need to spend 10,000 hours doing it.” Ask yourself have you put in that effort or are you expecting things too early.

It is a different story that also goes around ” I am architect but do not know what do to”. That is the topic of a separate discussion.

 

Create your product roadmap radar

Leave a reply

Most often in organisations we would want to create vision statements on certain capabilities that we want to achieve. At times this is in full display at coffee stations , common meeting points and in the stairways. At times these are simply in the form of certain xls sheets or mind maps tools which gets debated endlessly and post consensus are put down in ink on what gets on the plate first and what will be consumed later. All of this has umpteen rounds of discussion on what looks better and is lean and mean and is doable in a certain time scale. Most often what is seen of very high impact is what drives user experience lets say improved UI tools to solve the customer pain points in terms of customization / deployment or integration issues. We may have tweaked a certain algorithm deep down in the code which may improve database caching and save round trips end to end and improve performance. But this can at times go as a should have been done in the first place theory and what delights the customer is what he/she sees to use or touch etc. So it is beyond reason to debate what the customer likes and catches his attention. Most often have heard old timers whom I worked with saying customers were happy with character based terminals instead of browser / web enabled mechanism which improved tech quotient of the software but greatly increased the time taken to key in details to punch in a transaction detail on the screen. The customer in this case doesn’t care if you used jsp/ROR/Scala/Coffeescript/node.js or Ajax or html etc he is forever cribbing on missing his character based system. He was quite accostomed to inputting all of this without leaving his keyboard and now he needs a UI to distract him and has to leave the keyboard to do most of his tasks. You can justify saying we upgraded you to the latest technology but he would say a different story , you downgraded his precious user experience. This is beyond us when we are onset with different challenges to embrace the shiny new thing on the block at times driven internally, at times forced by a customer, at times marketing and sales driven. So in short we most often from time to time need to check what looks good on our roadmap or radar.

Build your product roadmap/radar 

product_radar

Was reading an article on the same from Neal ( Thoughts works ) on how they build a technology radar . Could see that this can be used in many organisations not just as a technology radar and in fact as a product radar to paint your picture to your folks. Most often this exercise is tough and challenging as now if you as a team commit to doing something and is on the radar then it is for everyone to see and measure where you reached. It brings people to commit to items on the product stack and keep them motivated towards their committed items. Of course you would need other factors to keep people motivated and that would be another story. For now lets say it helps people to focus on the vision statement and keep them hooked to it. 

Lets say we could apply this radar to a product roadmap. If we were to consider our product to a banking software tool , since I have worked most time on this domain. Lets say we have different product divisions (Corebanking/CRM/Channels/Treasury) internally in the company that wants to track their progress and what looks good going ahead and what needs to be watched , what needs to be dropped. With our fascination for quadrants and the following radar mechanism is handy to view where you want to go and provides a pictorial representation behind all the discussions that went into making this chart happen.

There is a nice explanation on the whole process of making the radar on what the different arcs represent such as nice to haves, must haves , trial and error pieces for the period and on hold items. All there is a nice thing that if you see some items as not having moved up the discussion from nice to haves to must haves then they simply fade away. Can be re blipped  when needed back on the radar. There is a nice little tool https://github.com/bdargan/techradar for plotting your radar which uses a JSON format structure details which internally uses polar co-ordinates to plot the radar. On the process and the details of how to arrive at this radar in your organisation Neal’s article is a nice read. on the thought works approach. My personal experience has also been same in terms of the consensus approach finally the person closer to the technology or the domain guys to have a major say. This apart if it is a pressing need from product strategy or marketing then it overrules all.

Go ahead build your own radar and it would be nice to hang around places where people spend time most else it will simply become a vision statement without follow up.

 

Summary Execute Execute Execute – Message from StartupCity2013

Leave a reply

startupcity2013

Was at the startup city 2013 NIMHANS Bangalore yesterday. Was fun/motivating/inspiring to hear from stories of struggle and eventual triumph hitting blocks and then tasting success at all scales from small medium shops to big success such as Chetan Maini ( reva fame), Arun Jain ( Polaris) , Cric Info founders , Gaadi / Galaata founders. The air smelled of entrepreneurship and Silicon India organized it paving a way for an ecosystem where like minded folks gather and discuss ideas big and small.

Listing down a few key takeaways  which are eternal in nature and many echoed the same.

Chethan Maini (Reva) ( Be passionate about your work) . Money is an offshoot of your work.         It is OK for people to laugh / not agree with your idea initially but believe in yourself.

Arun Jain ( Polaris)

Team building is being part of the team and not merely leading the team. Feel as if you are one.       Have many ideas what to do ? Stick to one idea , eat the idea, sleep with the idea and get up from bed with the idea and you will find success.

Padmaja Ruparel ( IAN Network)

A class B idea with a class A team is better than an class A idea with a class B team. Finally execution , execution and execution alone matters.

Balaji Parthasarthy  ( SnapFish)

Know what works for you and a team is better than an individual as more energy and diversity is put to use. Of course single founder exceptions could be there as well.

Many people think on the same lines finally whoever sticks or believes in their idea and takes it to conclusion gets the slice of the cake ( angels/VCs included)

2 Minute Elevator Pitch ( Tell me what you do in 2 minutes product/team/company etal )

The best part of the program was each startup was given a 2 minute elevator pitch to drive home the message what they do. Some performed great in the act and some still taking baby steps in their companies and products did not do so well although they might have great products. Overall no idea is mean or small there is a potential in everything that solves a problem or a society’s need for something.

Meet the VCs 

You did not need credentials to meet people to fund your ideas there were separate rooms for finding people to fund your ideas and evaluate them.

There were people other great people who were part of open discussions and finally the CXO conclave at the end of the day sharing their stories and thoughts on tech entrepreneurship in India.

Overall the event was great and nice to breathe the same air as that of the founders and CXO’s of various companies big and small under one roof. It was definitely worth hearing to many young turks who are on their way to creating something great and of value to the society. The startup culture is on its way and as per discussions now India is only way behind the bay area in US in terms of emerging startup scene. It is good to get yourself in there and get rub shoulders with a crowd who stick out and ready to tread a different path to achieve the destiny of their making. If you are not creating something then you cannot predict the future. Nice to know that alongside all the hard work and passion behind the scenes some sweet smells of success of companies could be smelt there. It is good to get the aspiration of people high by hearing of folks who have done it once/twice many times before you. You get a feeling that it is after all not something only a few could venture into…

Nice hangout on a saturday came back feeling Bangalore is happening on many fronts.

 

 

 

Put your Release and Build Team to Sleep….DevOps is here

Leave a reply

 

sleep

With a backdrop of the traditional waterfall mechanisms of project management, build and release was always pushed aside as the last but one activity before cutting the CD / testing certification of the software. The last mile as it was referred to this although was the last step in the journey towards a software delivery it would remind one of the famous lines the “Journey has just begun”.

Although this was the last step supposedly to be taking 20% or less of the actual effort it generally would be the other way around , taking a significant effort and often not scoped in estimates and it was quite OK to do so till recently. Start the blame game and developers blaming QA and vice versa and everyone including the other teams would take potshots at each other and say their part worked fine but the had issues in the final integration. All of this started to be stage managed with late nights and weekends going into getting all pieces talking to each other is all very familiar with traditional methods in place.

What next ?

There are some best practices such as the following that are being followed where everything is continuous meaning

Continuous Delivery
Continuous Integration
Continuous Deployment

What all of this means in short is every time you change any part of the product the whole SWAT team runs behind the scenes to check if all is OK with the system. Now if someone were to check in something that breaks the system then it needs to be fixed then and there. Have seen that code needs to be fixed corrected by the erring developer/team by the same night. There are protocols like call the guy involved to get it right and ensure only code that is working is checked in . All of this boils down to the Agile concept of everything that is checked in is tested and fit for deployment into production post a formal QA team blessing the product. But otherwise the usual suspects are nailed down early and the QA goes on to find the more grueling aspects of the product committed features which have escaped the unit testing/TDD iterations.

If something out here still finds its way to the bug tracker then the developer needs to take care of UNIT TESTING / TDD best practices on ensuring his/her code works well under all circumstances and integrates with all the surround infrastructure and allied pieces of software. Software ownership and craftsmanship are truly enforced here as this goes in a loop till the process achieves some predictability on the process.

continous_integration

DevOps in a five line code snippet for starters.

 

Learn to say No and You become an Yes Man

Leave a reply

Firstly say No to SQL

These days with the popularity of No SQL / No UML and everything No which was previously Yes we are now entering the No era of things. There was a time when traditional databases moved from plain old databases to RDBMS and it was the biggest paradigm shift of that time. Now it is get away with the overhead of everything that comes with RDBMS and move towards No SQL. 

Apparently the fact remains that SQL still remains a most sought after job skill to have based on indeed.com search listings. This movement reminds one of the era when certain medicines were considered good for health are found to have lost their relevance and things moved eventually to better things. Everything big is now embracing the No SQL movement , big data, big users (massive concurrent number of users) and cloud computing.  The data that all of us collectively keep churning out simply puts RDBMS out of the picture being capable of handling that level of scale. Once you open up your web delivery mechanisms to the app world(blackberry,strawberries, apples and all the fruits out there !! ) .You could potentially hit several hundred million hits in a short span of time. Much of the data is semi-structured and unstructured which does not conform to a normal schema and much less conforming to any data model.

Why No SQL Maps fits the Cloud Model

The traditional model of scalability is put a load balancer in between commodity servers and as soon as the users reach a set limit say 10000 users route them to a new server with a routing logic at the load balancer. This works fine at the web tier but eventually when the data comes over to the database tier , being centralized and share everything would create issues and help only scale up and not scale out would be possible. This meant dynamic scalability was not possible and easy.No SQL databases were designed to be distributed and help scale out as the distributed computing needs increases.

Why JSON is becoming the standard sought after ?

When dealing with dynamic data we often encounter data which can be outside strictly of the rdbms schema model . All of us have stories of how changing a parameter within a control structure of a three tier application or rather n-tier application is rather difficult . This over a period of time was met by linked lists and key/value pairing kind of solutions which would bunch newer data in this format and send it all the way to the database. At the database layer we would then need to disassemble them into respective DAO objects and push them into the respective tables. All this is fine if the table structure itself is not changing. If the table structure has to change then it would mean that changes in the following :-

1. DAO layer                                                                                                                                      2. Schema / XML / Meta model layer.                                                                                                3. Java generated boiler plate code for the db layer.

This is developer and release nightmare if needs to be done any which way agile or non agile in the shortest time to value cycle. In such cases developer would prefer to stack up all the information across db tables in objects and prefer storing objects as they were instead of in tables the traditional way. No SQL would mean now the entire JSON objects would get stored into the database as it is and can accommodate any free format. This would ensure that you aren’t fiddling around with the current application state in a disruptive way. Not knowing if poking something here would pop up something on the other side or at times the systems fails to come up.

Secondly say No to UML

Have heard the thing that UML is a big overhead. Most often we see people sure need to know how to document using UML but prefer the white boarding technique to charting diagrams. Post running through this in their head or code it first with back of the napkin kind of approaches then finally document the hard to understand must be read before cracking the code figures being put up via UML. Some prefer calling this as AML or Arbitrary UML but there are a lot of standards that are cumming up at least at an enterprise level that indicate a less techie and more friendly to the end users / business folks kind of language. ArchieMate is a step in that direction. But again you still need UML at all costs and needs to be given its due where required. But will not be the be all and end all of artifacts documentation and most people would agree it never was in the first place. There are tools which help to get the diagram and the code in synch but again haven’t seen or heard of this practice as been followed as the done thing.

Given the No to SQL and UML I am sure there will be many more along the lines of lean code, lean organisation and lean startup and many things lean on the NO movement. Say Yes to NO where applicable and you suddenly are a most sought after person indeed the YES guy….