Category: blog

Categories
blog

A Multi-Hued 2013 is behind us – Welcome 2014

multihue-2013

At the outset wishing friends , well wishers , clients , customers , contacts on linkedIn and twitter ,colleagues and ex-colleagues a Happy and Prosperous New Year. Every year brings its own shares of highs and lows , learning , lessons and at times keeping you guessing as to what is around the corner.

Quite a lot of things happened in 2013. It is now behind us and few moments left before we would be woken up into a brand new year. A small concise and brief list of things that touched me personally.

1. Became an adept smart phone user and started using many features. Realized that smart is not all that smart when it comes to power usage. It can’t have it all for now before we have some smart battery that replaces this nuisance otherwise a really smart add on which most of the population will sooner or later use.

2. Started using twitter and the 140 words is really a quick and dirty way to learn on things of your interest. You may wonder how is this possible , you can try twitter may be personally may be a late entry. But it is easy to understand what is happening in your arena if follow folks of your interest. No where in the history of mankind are people distanced by a tweet away. You can almost tweet anyone high or low from any country or race and voice your opinion.

3. The lonely boy fifteen as referred by Guy Kawasaki in one of his talks literally illustrates the power of the social media. Was able to voice my opinion on my twitter on two occasions where I expressed my displeasure on certain customer experience with products. Both the occasions the companies got back and try to win back the dissatisfied customer. This emphasized the power of social media where any brand is only as good as the last user experience. Good for the end users that big brands can no longer push things at them without a certain responsibility.

4. Lessons in how to run things by yourself when you start small ( www.eturnti.com). All things need to start somewhere and this was a step in that direction. All learnings here  give you a perspective of how it is to step outside and view things differently and more importantly make things happen. Thanks all clients and customers and folks who supported here and helped bring work to the table when it mattered.

5. An increase in the number of linkedIn contacts from all sections of the industry. Some people seriously interested in making connections others simply to extend the connection to tell their story (eturnti included). It is a good medium to showcase what you have to offer and tell your story .

6. Got to brush shoulders with people who have tasted success big and small and more importantly are out their to make a dent in the universe as Steve Jobs calls it. It is a humbling and learning experience to know all of them had started in a shack with no formal office / sophistication and no funding in the case of a few. Some funny cases of how people started out and some accidental entrepreneurs.

7.Every client is book in itself. What do you have to offer that he/she is interested in is a good question to ask before trying to sell your ware ?. Most of them have very specific needs and are rarely satisfied with an umbrella offering. Get specific and also distance yourself where you are not able to add value to the customer is a lesson here.

8. The young and old have started using technology. My family has a good exchange of messages on whatszapp apart from facebook. Who knows next it might well be snapchat. Anyway here have a see if the technology catches up before you get to use it. Bitcoin might eventually be the order of a cashless world . If that were to make things safe then you have cyber theives adding to the complexity. So always stay hungry and stay foolish before you are challenged.

9. You can almost sell anything these days including yoga and doctor services online which were thought of as the last things to be made available online as you need a personal presence. The world is shrinking and it is up to us to get our act in order to stay in tune with the new world order.

10. Meet people outside your area of influence it enhances your own sphere in ways that you thought not possible. Try it and find it out for yourself.

A robot will fly sometime soon from flipkart, amazon , ebay to gift your next New Year gift. This is not a distant thing as things stand today. We will be soon surrounded by robots . Be human and stay young at heart and keep staying foolish.

Categories
blog

XML or JSON which one to use ? What is the tradeoff ?

XMLVsJSON

Most often in projects we need to make crucial decisions when there is a need to freeze upon a standard , language or simple as a standard. Let’s say we have a simple design decision to be taken such as which is a better standard for messaging in the project where we are set with the task of say transmitting an account details from the UI of a bank for account validation. In this case let’s say our decision is influenced by legacy and we have some backend that understands XML then the natural choice would be XML of course if there is free will option left to choose. This is simple and straightforward. Let’s say some folks in the team are voicing in the favor of JSON saying that it is really simple and it understand Java Script and that the handshake between the front end code using java script and the messaging structure can be better coupled , as a architect / manager or IT decision maker how would you approach this problem. Obviously the expectation is that you need to have used at least one of them or at least be able to understand the nitty gritties of both and what they entail.

Which one to choose ( XML or JSON ) ? 

Let’s first get to know what is the likely usage of these standards in our application , this a good starting point as will ensure what is needed most for the scenario. It is not a good idea to have multiple standards being used across your application. 

You want to have a simple messaging style format across your application. 

Both XML and JSON are ideal candidates as long you keep your messaging format simple and not too verbose ( XML pitfall). Both are good simple ( if kept simple XML) , extensible , open and are interoperable as well.

You need to send across binary data or complex data across the wire.

If you need to transmit audio, video , images , chart , graphs kind of information then XML is a better choice for this as there is built in support for this . JSON is more for text and number like data which can be framed within lists and arrays. The flip side is JSON is simple and as it does not have this feature you can say that it is in a way secure for simple means of communication where hacks due to malicious exe and code cannot be embedded in the message format.

You need to send data alone in various related formats and not a whole complex document 

XML is good when you have to send document style data with attributes and meaningful hierarchical data which can be defined extensively using attributes and nodes. JSON on the other hand is useful when you want to send key value , array ( nested ) based data back and forth.

You need to create a markup language or new language with semantics to make some configuration easy.

Let’s say you want to customize some configuration for your customer and make it simpler for him to enter configuration data. You can go ahead and create a language with special semantics , this is easier done in XML with supported parsing and logic added to the code along the side. At times while the definition of this is easier it is tough to write the compiler semantics for the processing engine to act on behalf of the XML. JSON would not be used here where expression needs to be evaluated for example.

You want to reduce overhead with scripting languages such as java script , python etc.

JSON is an ideal choice here as the data format already resembles the notation available in these languages and it is reduces the overhead of conversion from one format to another. XML can also be argued to be a best fit with library support from the languages and scripting platform.

Overall both have their pros and cons and based on your context you can trade off one against the other and use it for your purpose. If it is an n-tier application it would not be a surprise where there is a XML end tier talking to a JSON tier with conversion / adapter logic written in between them , this would ensure both co exist where the need for them is justified in the application. This kind of trade offs are most often done in day to day decision making where architectural decisions are impacted based on what feature necessitates the use of a technology, language, platform or scripting .

It does not make sense to go with the latest on the shelf or our team likes this feature lets use it or that is the new thing on the block. Anyways these can be dealt with when technical leadership meets maturity and is backed with good experience having dealt with such choices.

Categories
blog

SOA is not the same as Enterprise Architecture

SOANotEqualsEA

SOA or same old architecture in other words is nothing new for people who have been using the concepts embedded as a part of this acronym in their day to day business. But for people or folks attempting a large scale transformation it still means migrating from legacy to a service oriented way of doing things. This explains why many still refer to as same old architecture. The same architecture is enabled in a service oriented way to enable others from calling services in your business function which will be useful to people integrating with your component or software. How do you do your transformation , do you attempt a big bang do it from scratch legacy modernization. What agile means are you doing in this transformation ? Do you care of delivering value in iterations or sprints . What is the risk mitigation plan in place when the services do not provide the whole value to the end user ? Are you risking everything , you do not have much of any option as you need to provide agility to business and that would be one of the business driver driving you to move towards SOA. There are multiple design patterns of enabling SOA based on your context , open source and Enterprise tools available to help in the migration. Does your team know what services to be enabled in what order of transformation to increase the perceived value to your business at the same time minimizing risk , cost and increasing visibility and measurability to your operations. 

Ways of Enabling loose coupling in your Architecture : 

1. Use appropriate messaging to solve integration needs.

2. Use EJB/RMI Style integration patterns ( or equivalent if coming from .NET architectures)

3. Use ESBs as the case may be , they are an overhead not always useful.

4. Use SOA Design patterns for enabling various best practices to resolve integration issues. ( many here from quick and dirty to structured / organized time and money intensive methods)

5. Reserve from scratch migration as the last option as this is time and money intensive.

It is akin to changing the wheels of a formula 1 car and still trying to win the race when others are still racing and not losing time in the overhaul when compared with the competition. This is risky in terms of providing an alternate path for existing customers who may otherwise be happy seeing their old system bottled in a new way not losing on the business focus and speed of migration. Experience here has been keep the old ways of doing things as the fallback at every stage , migrate to the new way when it solves the customer needs fully. Thereby you do not loose the customer in the process. This is where governance and plan in place will help things shape up. 

Why SOA is not Enterprise Architecture ?

SOA is an architectural style and some confuse it to be the be all and end all of Enterprise Architecture. It will not be a replacement for an EA solution to a problem. EA consists of many other things that go into helping an organization reap the benefits of good architectural practices and frameworks in doing better things. SOA while some ill informed may argue that it has a governance, loose coupling , agility , reliability and also has in itself the promise of organizing the architectural artifacts and at the same time solving a business problem. But as it has been noticed an Enterprise Architect ( a seasoned one ) can choose to pick SOA as one of the many architecture styles to solve an organization problem. With REST picking momentum it seen as an alternative to SOA in many cases where there is a strong case for REST and there is a compelling need to go the REST way. REST is far more extensible and loosely coupled than SOA and has easier integration patterns compared to traditional SOA design patterns. Again based on your context either may be the best fit.

Some common myths :

You need SOA to be 100 % all encompassing. Not true only encapsulate whatever is part of your stack into a service. If it does not provide or add business value then do not publish it into a service to the external world. If you cannot think of something as a service right now , delay the decision and be lean do what is needed for the hour.

SOA  you need web services to make it happen. Web Services is only a means to the end to enabling SOA. You can have SOA without having used any bit of web services.

SOA is not ESB or ESB is also not mandatory to solve your business problem. As long as people can connect to your service and orchestrate services in one form or the other it really does not matter if you use an industry standard ESB or open source solution.

SOA is enabled so we have a great architecture and all our problems of scale and loose coupling are behind us. This is also not true if you have not adhered to principles of loose coupling all long the layers including the data or resource tiers. Only if done well this would mean good SOA else you can have a bad architecture in the name of loose coupling. So you have use the best practices at some layers but underneath the hood you still have spaghetti code all sticking to each other as in the case of a monolithic application and that is not way was intended moving to SOA.

So use SOA to solve your integration problems and remember to use the best practices to do it the right way at all layers. Some may even say SOA is EA it is like saying a well oiled machinery smoothly running is the same as an entire organization or vehicle which is using that machinery. SOA is an ideal fit for helping your EA practice run smooth where it fits well. Most often this term is well en-grained in the DNA  of product development in many organizations, but where people move away from legacy to attempting to do it from scratch they need to focus on the essentials meaning back to SOA design principles to get the right cadence from your architecture. Good SOA is definitely is a good EA practice.

Categories
blog

Centralize Interoperability and Decentralize Implementation

decentralize_implementation

Most often in Organizations we have a crucial process that most often is referred to as governance or project monitoring or simply operations at times. What this means is to look for facts and figures and data in the system that are not aligned to the organization vision / mission long and short term and set things right. Do what is required to set things right including pulling one’s hair out / fire fighting or simply status meetings and reviews. In the midst of all this various governance / steering committees are created which acts as custodians or guardians of organization know how or the gatekeepers keeping a vigil on how things are done.

Turn your developers into Rock Stars and Managers Into Rock Star Promoters is an other way of saying give developers the freedom to do things that they do best and let architects/managers do what they can see and the developers cannot see. This means things like getting an approval for a module specific change deep down in one’s own code ownership should not involve going around people to get approval. Decentralize these kinds of things in the organization with adequate code review / test unit process and ensure overall sanity of the changes. We do not need much effort on this front to set things like this rolling. Whereas lets say there is a change that crossed two product solutions / interface and involves a messaging layer change or impacts one or more teams solutions. In this case Centralize this Interoperability aspect and ensure the stakeholders from both sides are involved including people with the right skills required to take the decision are present for deciding on these changes. This way architects/managers or senior members of staff who are capable of taking a decision on this should be involved in such decision committees. This ensures there is less red tape in the system and more control at the same time where required and adds value.

Saves Time / Money and Precious Organizational collective time : At times every organization gets caught up in first setting up a process and then breaking the law themselves when it becomes too rigid to follow. Review your process every now and then and follow this principle to eliminate waste occurring due to collective involvement of people not really adding value to the process. Also this would promote organizational flexibility and agility where people go ahead and make changes confidently , check in the code and prevent show stoppers in the pipeline. Remove the barbed wire/fences here would ensure people feel encouraged to owning things up and cleaning up their act. Instead if we route all things important via a central decision making body then it is invitation for disaster. Developers who shy away from meetings will not be ready to even raise these issues fearing a meeting with all and sundry and having to explain the rational which may not make sense to others. Yes empower them and also ensure that the are enough code review processes/checklist for various modules/process which people are following. Also the source control repository should have details on who checked in code/artifacts and back trace it with a  ticket tracker. Once this is there in place then let loose the need to monitor every thing that goes around. Instead use this time to review things that span product interface boundaries , cross solutions where there is a real need for tight control and strict governance.

Release the barbed wire around your teams and let people contribute/own things and co create greater good for the organization. At times it is good not to have any formal authority and works well in smaller teams where agile practices are practiced and but this concept can be extended for an extended enterprise which would be agile at scale scenarios.

Categories
blog

Do you scope NFRs in the beginning or end of your product/solution ?

NFR_1

There are multiple questions that come up when we think about the NFRs in our product or solution. The normal practice is these days accept they will show their head in the product eventually but feign ignorance at the beginning of the product / solution as you are busy doing other things , like getting the product up and running. Most often you know very little about these in full detail at the start of the project or work. You may know that there are some implicit NFRs like the user should not experience unacceptable delays or his/her UI experience should be good. These are like eating food at a particular restaurant and having to comment on it. Many people have many views.What would be the common denominator here ?

When you scope the design of your product / solution it is quite accepted that these creatures are usually hard to deal with are there but you know they will not pose a danger immediately and you can be friends with them at least. So what is the accepted way to design NFRs or look at them at the beginning of the start of work.

While you prepare your enterprise or business requirements take a note of the fact of what the product is all about. You cannot get all of them right here , accept it. As the product is itself evolving there is very little knowledge of the system in the beginning. You have a product in mind but as you see the wire frames, screens, prototypes and the product itself in some form on the road you will be able to get to know where to head with your NFRs. Most often this is true that you do not even know the exact number of users who are going to use your system directly or indirectly. So the sane way forward would be to crystallize your enterprise/strategic and business requirements and use your judgement to see where these will impact your solution/product and allow scope for these in some little way at the start and keep evolving from there on.

Things to do to scope your NFRs in the beginning of the project or work :

1. Understand  your product / context / solution in good details and who your end audience is going to be. What mediums/channels will they be using your product / solution. Leave no stone un-turned here such as what channels , devices they will be using including handhelds/phones/laptops/smart phones and what exact versions will be used here. Do check the list of user bases in these categories and arrive at what will be done to scope the needs of these people who will be using your system.

2. Have a NFR checklist / template and be aware to use them on how they might impact your solution. These are either organization repository artifacts or industry specific ones available / published as a part of known things to be taken care of. This will help you with at least glancing through some of them even though they do not look obvious at the start of the project. Here is a look at high level list from the ISO 9126 wiki list read more.

3.  These templates are extensive questionnaires dealing with all the types of scenarios that the user can land. Go through them with the performance validation folks or sit through people who have done this and arrive at the complete list specific for your context. Have a list that covers your requirement.

4. Conduct a series of short workshops either one on one or select participants who have knowledge of the business or context and then work towards preparing the list of NFRs the system should be ready for. This will reveal a lot about the system , talk to the end users , people who have been playing around with the system and test people.

5. Throw open your solution to folks internally in the system if there is already some form of solution that you are planning to improve upon. If it is a totally new from the scratch solution there may not be any organization knowledge on how to do things here. Do let the people who have UI experience , the end users give them your inputs or experience here. This is generally the case of a patient who knows more about a particular disease than the doctor on the same subject. Take all these and add your own judgement with due diligence here.

6. Get experts in each area be it security, performance, clustering, load balancing, UI to give them their gyan on how they approach these issues. Get these vetted against what you have scoped already. Have a sign off from all those who can cross check and use this baseline as your initial list.

Scope everything that can go wrong with the system and plan for them. 

As with systems more clarity will emerge as we go around iterations of the product and things get more refined and clear. Also when you design your system always check for the alternate flows on what could go wrong with your system in all the flows. If you are using a messaging system or third party provider for SMS messaging then check what if one message gets lost along the way. This will help plan for some really crucial quality attributes here. As your system evolves your functionality although was the same from day one you will find the same being presented in multiple ways to the end user.

These steps as a starter will help get you out of the alligator pond where your only option would be be friends with these creatures or risk being eaten up.

Categories
blog

Why Sign both the Manifestos Agile and Software Craftsmanship ?

signhereorthere1

This question is more like you what if you were asked to sign for two rival organisations one pitted against the other. In a communist regime it would be akin to siding with the dictator and other with the rebellion groups at the same time. On one hand we had the agile manifesto which brought to the table best practices of XP which later took over to Scrum and now there is movement called Software Craftsmanship which is gaining momentum. It was always there but it just that it is resurfacing itself with more necessity now. Need a Surgeon who follows all the procedures correctly and also does a good job of the surgery. This is how we need to see both these movements Agile and Software Craftsmanship movement.

What is Agile manifesto ?

  • Individuals and interactions over processes and tools
  • Working software over comprehensive documentation
  • Customer collaboration over contract negotiation
  • Responding to change over following a plan

Remember the initial agile thing  that we got to practice was that of Extreme programming and it sounded as if we were doing something out of the way. Not certainly new things but old things in a newer faster effective way. It got people involved in the whole process and brought a lot of mileage and visibility in the organization. A little later came Scrum and other lean and mean characters followed.

While all of these got practiced by people , the craft of delivery good software got lost along and it became more of a process rich methodology with backlogs, sprint run race velocity and a lot of jargon thrown along the way. We left the main essence of all our work which is to write good software aside and got carried away by all things agile. Little realizing that if we sulk on writing good software then it will eventually slow us down no matter agile or otherwise.

Just as we have good engineers doctors who take pride in laying a state of the art bridge or performing complicated surgery , an expert software person these days is almost dealing with the same set of tools and many a times doing mission critical jobs which are at risk if we leave the craft aside and focus on delivery alone.

 What is Software Craftsmanship ?

  • Not only working software,but also well-crafted software
  • Not only responding to change,but also steadily adding value
  • Not only individuals and interactions,but also a community of professionals
  • Not only customer collaboration,but also productive partnerships

Why we need Craftsmanship in good measure along with Agility ?

Technical debt increases in the project as it progress if the initial thought process to create an architecture which forms the bedrock promoting flexible changes end to end is shallow and not done correctly.

Most often we know how quickly we ended up doing a POC or the initial releases of the product. As we progressed things got slow to the point where there were instances where a customer wanted a font change or a logo change on some index.jsp but we ended up saying it is going to take some obscene amount of time citing organisational procedures, bureaucratic red tape , QA , testing of all forms , our platform certification practices etc. This is true of even the big boys when we request a small change in any software of enterprise level, all we get to hear is yes we have considered it but gives us time till next release and we will put it right back in there. All of this is familiar to most of us when things looked quick doable in a jiffy but as the product matures ,egos rise and technical and product debt increases we find ourselves like the rain starved farmer looks at the skies for divine intervention. This could have been avoid if we focused on Software Architecture best practices and craftsmanship of some form. The better the skill less is the debt . We have existence at all levels so we could have various forms of craftsman some more skilled than the others and others not even acknowledging that there needs to be one on the team. If we do not pay heed to software quality and design principles , architecture best practices , code best practices and correct things then and there we will be debt ridden and eventually end up with the debt being written off meaning scrap the product line and look at rewriting this.

There was this joke going around in one of the companies , there are 50 people working on re-factoring the product and the unofficial hear say was you need half the time and only 15 people to rewrite the product completely from scratch. Most often you cannot digest the fact that scraping something altogether is worthwhile , just as we have an old item in our house that served its purpose but now occupies space and does less. Of course while we value that it served us well and enabled us to get this far and when we want to do something different then we should be able to redraw our priorities and align our needs accordingly. Writing good software is an art with more of a process like if we get X people certified on Y technology then we can reap Z benefits over a period of time. This rarely works although most often this gets practiced everywhere. Just as of all the people who learn a language only some manage to write poetry that can move minds and souls. It may not be a good analogy as we have fewer poets than software engineers these days.In a similar fashion while we need agile practices to help us quickly add scale to our operations we also need to have the craftsmanship part of it to go hand in hand. Else we will have a process rich methodology without craftsman who can execute on the promise of the Agile story. We could look at in more detail what constitutes craftsman ship in an other thread.

So sign up for both if you want to sow the seeds as well as reap the rich harvest.

Categories
blog

Why are benefits difficult to calculate in software investment ?

Cost benefit analysis is a good tool to estimate the ROI based on investment in software. It is a simple formula that says

Cost/Benefits Ratio = Benefits of the Solution-Product /   Service Cost of investment.

This simple looking formula enables ones to calculate the cost of investment against the benefits of the investment.

Let’s say we have two competing product line items one of them being revamping our click and install strategy and the other one being upgrading to a new application server. Let’s say the click and install strategy brings to the table the benefits of a literally one click install and there are no ambiguous things in the installation and every thing that the customer/ install engineer needs to do at site or on the target box is well defined and crystal clear. This is an area which involves folks from different modules to collaborate and provide their inputs to the installation team.

Overall what does this involve : Individual teams ( collect all your artifacts and hand them over to the install team) , install team ( collects these artifacts and includes them in their batch installation process/software reorganizing what comes first and second and so on). Now this simply means two teams at work one team is simply a provider of data having very little to do from their side at least at the start of the program to enable the grand vision of a one click install. The other team is busy with the data obtained from teams and busy fine tuning their install elements and getting the software installation in place. Lets say individual teams put together spent 5 developers ( 2 days ) to flesh out the details and around combined effort of 2 man months ( 5-6 developers from each team fixing the the changes for the single click install – this could have further broken down into consultants / developer partners and members of the company – aggregate the numbers here and total them into man months and convert them to a FTE and say you arrive at 2 man months of effort. If we calculate an 8 hour work week then if the charges are around 300$ per day by some outsourcing company and let’s say the cost to company of a in house developer is 100$ ( minus salary / training / benefits etal) . To keep things simple we say 2 man months was the combined time taken across teams to release this feature meaning a shippable product with rounds of QA thrown in adequate measure.

Cost of spend on one click install  =  2 man months * 60 days ( holidays included) * 450 ( Average rate of internal and external teams) = 54,000 $

Lets say check benefits of one click install  :

Banks operational staff is cheerful with rolling releases / bug patches and defect fixes. They talk good about your product with other vendors who are SI at a particular engagement.It takes only one of the usual Joe’s to fix and avoids 4-5 people late at nights on friday weekends. ( This is tangible direct revenue can be associated with this / weekend / late night allowance included in happier times else it is sheer push that works from one and all to get the rollout ).The support team uses less cuss words and your effort begets good karma. Wait and watch. Apple effect to follow.Earlier if the rollout took combined effort from several teams for a stretch of days on end and finally breathe easy now you can probably do it in much less time . Tangible value here as well.

On the other hand let’s say the application server install  let’s say took 2 people from 5 teams to finish the work internally without outsourcing in 3 weeks time and this adds up to 2 (developers)* 650 (per day rate) * 5*15( days) = 97500 $

Cost of spend on application server migration = 97,500 $ + 50,000$ License fee of the product certified.

Now if you have the product rolled out in different markets then cross sell , up sell opportunities can also add up to revenue. Can this could make up for sunk capital on this feature. But again this would be from a pure financial gain point of view.

Benefits of migration to application server migration : 

You are seen as leading technology changes from the front. Customer gets to know from you directly instead of he having to ask you to migrate because the rest of his surround system is already on the new platform and having to pay recurring license on an off the shelf product is becoming expensive and illogical. As you grow bigger your problems are bigger. There was a case in point when someone wanted a feature to be turned OFF in the product, that was in itself a project and not justifiable. Here again technical debt , software craftsmanship and other in the fraternity come in handy if you were pally with them initially.All of this call for a definite method in the madness approach. Do you have teams who look at software delivery like a relay or more like a close knit game were all are involved from start to finish.

Now coming back to the question of tangible benefits it would less memory footprint , better resources and more value for money spent on the hardware boxes. CTO heard less of our investment in X9000 series machines with Y investment still chokes on wednesday at 11.00 am every week. Less memory footprint would indirectly increase CPU responsiveness and provide more head room for multiple applications to work along side without peaking and frozen behaviors.  You can arrive at some benefits here in terms of saving and additional hardware resources or if you are in the cloud already think of less pay as you use cases. Some tangible benefits. Attaching precise X dollars is again a challenge as many factors would be involved. 

Lets say you have brainstormed internally with your teams and arrived at cost benefit analysis for three solutions at a prototype level and are stuck at which one to pick. Then the following calculation would be useful. But there is usually more to it than just the financial aspect to it as we saw above.

costbenefitanalysis

The above is a cost benefits analysis for three competing solutions and solution Y has the maximum benefit to the cost incurred if we were to consider from a pure financial point of view. Most often technology folks are immersed deep down in technology issues and challenges and at times do not see this side of the story. But the decision makers and people who approve the cost of spend on technical projects would need this and additional mechanisms such as PERT ( where probability or chance of success also is a parameter in the calculation ) to arrive at or narrow down the choices before sponsoring the projects. At times we even have rational such as we have some additional folks on bench so lets kick start this project on the side and add value along the turns. In such instances we incur benefits once the software is delivered value realized and when we are able to push the product out there in the market.

There is also the story of twitter , you tube which for the longest time were funded with out any benefits in sight in such cases the above rationale does not hold much weight except of course for making decisions which eventually made up the twitter or you tube. Anyways it is nice to be equipped with this knowledge at some point of time and if you are continuously innovating then obviously the value is hard to calculate and benefits are bound to flow. So know when benefits need to be applied and when innovation culture precedes all then benefits although intangible is an immediate after effect.

Use calculations with the knowledge that you have on systems and then benefits would become easy to comprehend and calculate. So the question remains at large although answered on some fronts.

Categories
blog Videos

Use a Balanced Score Card For Your Organization


Balanced Scorecard is a effective technique to monitor and set strategic goals for Organisation. It has endured twenty years of existence and is an effective tool used in Enterprise Architecture and used widely across enterprises big and small.

Need one for your organisation when you need to revisit goals and set new ones. Track them to closure and make strategy everyone’s business instead of being handed over from the top. Watch this video on how to arrive at a basic BSC for your Organisation.

For more training

www.eturnti.com/training
https://eturnti.com/enterprise-archite…
asketurnti@eturnti.com

Categories
blog Videos

What is Enterprise Architecture?

More people in the line wanting to become architects/managers , join an architectural practice, better your existing knowledge levels and people wanting to climb the architectural / managerial ladder in your organisation can augment your skills and can benefit from this training.

What is EA is it a body of knowledge , bunch of frameworks, tools , practices , methodology , best practices ? Know what it is to know what goes behind EA practices and how they are applied to situations and derive value and showcase improvement in the organisation.

Categories
blog

How to demo stuff to people ?

How to demo stuff to people where a sense of how it works is evident and you get a sense of being taken through a journey. Tell it like a story as it is told means you are no longer the guy who is shown how the stuff works but almost get to experience what it means to own or work with that product / tech stuff or gadget. There are many  books being written on this topic such as slideology, presentation patterns and effective presentations and so on. Each of them giving you on what is needed to convey your essence to the consumer of your talk. There is a great deal of learning that Steve Jobs added to this topic and many refer to him as the epitome of someone who told a story and that too a captivating one. No one presented like Steve was the standard. Men of his caliber apart from marketing apple to the world around did in many ways up the standard for presentations and cut down on all the flab that goes with presentations. Carry with you the item that you are going to demo , build a story around it weave it together and the world is the stage for the actor/presenter.

Watched this nice presentation on regular expressions which is always an interesting topic where you can do many many wonderful things with regular expressions. It is skill which can be a great time saver and a productivity tool in software development. You learn this skill to keep your bosses and coworkers happy and most of all solve complex problems and find simple time saving solutions to perhaps writing a tool to automate tests, find the up time of a server, find CPU,memory ,RAM usages and where ever else one can lay their hands on writing scripting to ease the job at hand.

This video had everything neatly explained and is a great demo right from the way the title was named /Reg(exp){2}lained/: Demystifying Regular Expressions. The title style itself is written in a sort of regular expression way , look for the data between / / and replace it with Demystifying Regular Expression. Great presentation and a tool used in the demo written in java script is available at http://leaverou.github.com/regexplained . Tell your story and you no longer have to present it similar to love the work you do and you no longer have to work.