tag:blogger.com,1999:blog-10344568418057185132024-02-20T18:43:32.005-08:00My Spilt Beans"My Spilt Beans" is my viewpoint of software technology and its place in the corporate world today. It covers (or atleast wishes to cover) a wide range of topics primarily useful for people who intend to use software to solve their list of issues.Anonymoushttp://www.blogger.com/profile/12651125370890137864noreply@blogger.comBlogger2125tag:blogger.com,1999:blog-1034456841805718513.post-31132158047067308112010-03-07T21:18:00.000-08:002010-03-08T03:26:30.381-08:00Enterprise Architecting the right way: A money saver<div style="text-align: justify;">I was having this discussion about Enterprise Architecting with a colleague the other day. After being elevated to the position of a Technical Lead/Product Architect, you never really get to do much but discuss (about how to get it done, among other things ;) ). We never knew when the discussion changed from a harmless talk to a heated argument. But at the end of it we agreed on two points. <u>The first and the primary rule about Enterprise Frameworks and Applications is: <b>don't do it</b></u>. <u>The second rule is, if you must, <b>keep it simple</b></u>. Think about these advises and I assure you, as a software company, you will save a lot of revenue. I have justified my opinion in the following simple '<b><u>to-remember</u></b>' points.</div><div><div style="text-align: justify;"><br /></div><div style="text-align: justify;"><b><span class="Apple-style-span" style="color:#660000;"><u>1. DON'T GET ME WRONG</u></span></b></div><div style="text-align: justify;"><br /></div><div style="text-align: justify;">You might wonder what kind of an advice that would be. <b><u>Don't do it</u></b>. Of course, we want to do it. We want to build a product or a service. </div><div style="text-align: justify;"><br /></div><div style="text-align: justify;">Don't get me wrong. I am not advising against creating a product or service architecture for client companies. The advise states that, do not complicate the matters trying to come up with a very complex structure for the implementation. And in most of the cases, it turns out to be the other way round. People tend to make it complex to make it look nice to the client. Actually. And the clients seem to like it.</div><div style="text-align: justify;"><br /></div><div style="text-align: justify;">I am not implying that complex is bad. But in my years of experience, I have seen unduly complex architecture tending to be useless beyond the first time. Such architectures are rigidly built. Hence they are not that flexible to accommodate much customizations. </div><div style="text-align: justify;"><br /></div><div style="text-align: justify;">The problem, here, is that with more and more client implementations, the software company becomes loaded with more and more complex and huge architectures per implementation with probably a lot in common. This leads to recruiting more developers and keeping them on board simply because, we need to sustain the implementation of these architectures. Why? Because a client somewhere might be using it. An enhancement/bug, and the there must be someone to address it. </div><div style="text-align: justify;"><br /></div><div style="text-align: center;"><b><u>Simply put or deduced, the cost incurred by the software company rises exponentially.</u></b></div><div style="text-align: justify;"><br /></div><div style="text-align: justify;"><i><span class="Apple-style-span" style="color:#FF0000;"><span class="Apple-style-span" style="font-size: small;">I have enlisted some of the specific cases at the end, if you are interested, where some of the companies(no names of course :) ) I know, have made some serious mistakes. The intention of this blog is not to bash companies up. It is to point out where you can avoid making such mistakes. I will keep updating the list.</span></span></i></div><div style="text-align: justify;"><br /></div><div style="text-align: justify;"><b><u><span class="Apple-style-span" style="color:#660000;">2. KEEP IT SIMPLE</span></u></b></div><div style="text-align: justify;"><br /></div><div style="text-align: justify;">As a software company, you should be more worried about making and using a reusable set of components as a part of the architecture. Break the structure of your product/service down to such a level that developing it in a modular fashion would be a cinch. The design phase of a project (product/service) is meant to identify exactly this. And we end up missing ONLY this. </div><div style="text-align: justify;"><br /></div><div style="text-align: justify;">Don't worry people. It is not rocket science. It is very simple. <b><u>BREAK IT DOWN and PLUG IT TOGETHER</u></b>. Believe me, down the line, most of the components will get reused. And you need a smaller set of workforce to tackle issues/enhancements with these components. This way it is not only efficient, you save money with lesser workforce and also plan for the future.</div><div style="text-align: justify;"><br /></div><div style="text-align: justify;"><b><u><span class="Apple-style-span" style="color:#660000;">3. BREAK IT DOWN and PLUG IT TOGETHER</span></u></b></div><div style="text-align: justify;"><b><u><span class="Apple-style-span" style="color:#660000;"><br /></span></u></b></div><div style="text-align: justify;">In the design phase, if you observe, a company is ready to invest a lot of time and hence money in tackling the specific issue. Nobody (sorry for the irresponsible allegation, but there are times when the truth must be told) invests even a little amount of time/money to go one step beyond and see if anything can be made reusable for the future. Or even reuse something from the past projects. (Believe me, I have heard from a project manager saying, </div><div style="text-align: justify;"><br /></div><div style="text-align: justify;"><span class="Apple-style-span" style="color:#006600;"><i>"Ok, I think we need to redo this module for this current project. Using something from that past project will require some customizations. No point in using that". </i></span></div><div style="text-align: justify;">Or something like </div><div style="text-align: justify;"><i><span class="Apple-style-span" style="color:#006600;">"Umm .. thats not the problem we are trying to solve Jay. I need you to focus on coming up with a specific solution to this problem. We will worry about it if ever the need arises."</span></i> </div><div style="text-align: justify;">to suggestions of making something generic or reusable that seems like it can be.)</div><div style="text-align: justify;"><br /></div><div style="text-align: justify;"><i><span class="Apple-style-span" style="color:#FF0000;"><span class="Apple-style-span" style="font-size: small;">I am sorry if it seems like that post where a frustrated employee takes on a manager for something he might have done. This isn't the case. But these are the cases where you have to get it right. </span></span></i></div><div style="text-align: justify;"><br /></div><div style="text-align: justify;"><b><u><span class="Apple-style-span" style="color:#663300;">4. HOW DO I DO IT?</span></u></b></div><div style="text-align: justify;"><br /></div><div style="text-align: justify;">The correct approach, according to me, is have a split design phase. One part of the design phase focuses on the project deliverables and then detailing at the technical level. Once this has been established, the other part of the phase is to identify the reusable components from the past projects and those which can be made reusable now. To start off, this phase induction is good enough to get us started on the re-usability.</div><div style="text-align: justify;"><br /></div><div style="text-align: center;"><b><u><span class="Apple-style-span" style="color:#000099;">Otherwise, think if all the hardware of the world or all the cars in the world were to come as one solid single piece, what good would it be?</span></u></b></div><div style="text-align: justify;"><br /></div><div style="text-align: justify;"><br /></div><div style="text-align: justify;"><i><span class="Apple-style-span" style="font-size: small;">I will cite the instances as soon as I compile the list.</span></i></div></div>Anonymoushttp://www.blogger.com/profile/12651125370890137864noreply@blogger.com0tag:blogger.com,1999:blog-1034456841805718513.post-68710546505924709312010-03-01T17:59:00.000-08:002010-03-09T21:26:23.607-08:00Solution Consultants : A Philosopher's Stone<div style="text-align: center;"><span class="Apple-style-span" style="color:#0000EE;"><u><br /></u></span></div><div style="text-align: justify;"><span class="Apple-style-span" style=" ;font-family:georgia;">Congratulations !!! If you are reading this blog, it means, you have already taken the decision to use software to solve your list of business issues. Most probably, by now, you must be inviting proposals or receiving them from prospective vendors for the same. If you are at this step or just before it, take a minute to read this blog. I assure you that you will start thinking more clearly after this. Or atleast, this blog will give you an argument to consider.</span></div><div><span class="Apple-style-span" style="font-family:georgia;"><br /></span></div><div><span class="Apple-style-span" style="font-family:georgia;">Some simple observations.</span><div><span class="Apple-style-span" style="font-family:georgia;"><br /></span></div><div><span class="Apple-style-span" style="font-family:georgia;"><b><span class="Apple-style-span" style="color:#660000;"><u>1. WHAT DRIVES THE DECISION</u></span></b></span></div><div><span class="Apple-style-span" style="font-family:georgia;"><br /></span></div><div style="text-align: justify;"><span class="Apple-style-span" style="font-family:georgia;"> How does a business decide when to implement a software solution for its needs? 9 out of 10 times, it is the business users or the customers of a product/organization that drive it to take the decision to implement the software. This is, then, taken up with the CTO who drives the implementation. Sometimes the CTO becomes emphatic to the fact that the organization is doing too much of its work in the most favorite spreadsheet solution. The need for the software is born.</span></div><div style="text-align: justify;"><span class="Apple-style-span" style="font-family:georgia;"><br /></span></div><div><span class="Apple-style-span" style="font-family:georgia;"><span class="Apple-style-span" style=" ;font-family:Georgia, serif;"><div><span class="Apple-style-span" style="font-family:georgia;"><b><span class="Apple-style-span" style="color:#660000;"><u>2. PROPOSALS FROM VENDORS</u></span></b></span></div><div><span class="Apple-style-span" style="font-family:georgia;"><br /></span></div><div style="text-align: justify;"><span class="Apple-style-span" style="font-family:georgia;">The CTOs, then, spread a word amongst their circle trying to look for vendors. They also contact re-engineering consultants who look for vendors in their circle. These vendors forward their proposals after understanding the detailed requirements and, if possible, arrange for a demo of the capabilities of their software tuned to the CTO's requirements. The word spreads around and more proposals start flowing in. </span></div><div style="text-align: justify;"><span class="Apple-style-span" style="font-family:georgia;"><br /></span></div><div style="text-align: justify;"><span class="Apple-style-span" style="font-family:georgia;">This is a traditional approach of getting software implemented. Pictorially, it can be depicted as below:<br /></span></div><div style="text-align: justify;"><span class="Apple-style-span" style="font-family:georgia;"><br /></span></div><div><span class="Apple-style-span" style="font-family:georgia;"><span class="Apple-style-span" style=" ;font-family:Georgia, serif;"><a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjOXOYO2WWxJppp3ZEpPGmUZ5GByplOn442YKrqvHQBOH5IRwinugXJDmEuXyJCGGsXZUNNqG9nI8XzImM5h1AsojOWBJYtnqYjyJWfUDt7ZP8crG6sMS8qckFKOw34wY6fL0Hacwre6Yiv/s1600-h/business_process.PNG"><img src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjOXOYO2WWxJppp3ZEpPGmUZ5GByplOn442YKrqvHQBOH5IRwinugXJDmEuXyJCGGsXZUNNqG9nI8XzImM5h1AsojOWBJYtnqYjyJWfUDt7ZP8crG6sMS8qckFKOw34wY6fL0Hacwre6Yiv/s400/business_process.PNG" border="0" alt="" id="BLOGGER_PHOTO_ID_5444340963024054626" style="display: block; margin-top: 0px; margin-right: auto; margin-bottom: 10px; margin-left: auto; text-align: center; cursor: pointer; width: 227px; height: 400px; " /></a></span></span></div><div><span class="Apple-style-span" style="font-family:georgia;"><br /></span></div><div><span class="Apple-style-span" style="font-family:georgia;"><b><span class="Apple-style-span" style="color:#660000;"><u>3. ISSUES AND INVOLVEMENT</u></span></b></span></div><div><span class="Apple-style-span" style="font-family:georgia;"><br /></span></div><div style="text-align: justify;"><span class="Apple-style-span" style="font-family:georgia;">The problem with this approach is that, the CTO and his team ends up spending a lot of time in this process. The pain doesn't end after finalizing the vendor. Once a vendor is selected, the CTO will now need a team on his end to follow up with the vendor from the requirement phase to the implementation and then onto support. You can see the involvement of the CTO's team's involvement from the picture shown below.</span></div><div><span class="Apple-style-span" style="font-family:georgia;"><br /></span></div><div><span class="Apple-style-span" style="font-family:georgia;"><span class="Apple-style-span" style=" ;font-family:Georgia, serif;"><a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjvzneGGcfJZZe_IjsaxH_0RKv_XcABl3wcD4mW0gD68hpOdbwusBuTvsawUgltLgCAcIb1M41AP2h7f-Tuf4nBJc94YurCY1pQ-3lDdX4-CulfOjAJzCU6KbqnxTu4leV0zXhVuzCN3sPu/s1600-h/cto_team.PNG"><img src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjvzneGGcfJZZe_IjsaxH_0RKv_XcABl3wcD4mW0gD68hpOdbwusBuTvsawUgltLgCAcIb1M41AP2h7f-Tuf4nBJc94YurCY1pQ-3lDdX4-CulfOjAJzCU6KbqnxTu4leV0zXhVuzCN3sPu/s400/cto_team.PNG" border="0" alt="" id="BLOGGER_PHOTO_ID_5444347391086893730" style="display: block; margin-top: 0px; margin-right: auto; margin-bottom: 10px; margin-left: auto; text-align: center; cursor: pointer; width: 400px; height: 351px; " /></a></span></span></div><div><span class="Apple-style-span" style="font-family:georgia;"><br /></span></div><div><span class="Apple-style-span" style="font-family:georgia;">Enumerated, it will appear as:</span></div><div><ol><li style="text-align: justify;"><span class="Apple-style-span" style=" ;font-family:georgia;">Arrange and participate in the discussions to explain the requirements to the vendor (MOST IMPORTANT).</span></li><li style="text-align: justify;"><span class="Apple-style-span" style=" ;font-family:georgia;">Initiate the development cycle and track the progress of the development (all the phases in the software development) eg. the Go-Design, Go-Develop, Go-Test, Go-UAT, etc.</span></li><li style="text-align: justify;"><span class="Apple-style-span" style=" ;font-family:georgia;">Follow up with the vendor in case of any changes. </span></li><li style="text-align: justify;"><span class="Apple-style-span" style=" ;font-family:georgia;">Raise software change requests, approve invoices, finalize effort estimates for changes and development, etc.</span></li><li style="text-align: justify;"><span class="Apple-style-span" style=" ;font-family:georgia;">Create detailed test cases for the phase.</span></li><li style="text-align: justify;"><span class="Apple-style-span" style=" ;font-family:georgia;">Test the software.</span></li><li style="text-align: justify;"><span class="Apple-style-span" style="font-family:georgia;">Post the software for the business users to test (UAT).</span></li><li style="text-align: justify;"><span class="Apple-style-span" style="font-family:georgia;">Production deployment.</span></li><li style="text-align: justify;"><span class="Apple-style-span" style="font-family:georgia;">Arrange for support vendor/team to manage support once the software goes live.</span></li></ol><div style="text-align: justify;"><span class="Apple-style-span" style="font-family:georgia;">etc.</span></div><div style="text-align: justify;"><span class="Apple-style-span" style="font-family:georgia;"><br /></span></div></div><div style="text-align: justify;"><span class="Apple-style-span" style="font-family:georgia;"><b><span class="Apple-style-span" style="color:#660000;"><u>4. PHEW</u></span></b></span></div><div><span class="Apple-style-span" style="font-family:georgia;"><br /></span></div><div><span class="Apple-style-span" style="font-family:georgia;">Guys! The CTO does really work hard.</span></div><div><span class="Apple-style-span" style="font-family:georgia;"><br /></span></div><div><span class="Apple-style-span" style="font-family:georgia;"><b><span class="Apple-style-span" style="color:#660000;"><u>5. SOLUTION CONSULTANT</u></span></b></span></div><div><span class="Apple-style-span" style="font-family:georgia;"><br /></span></div><div style="text-align: justify;"><span class="Apple-style-span" style="font-family:georgia;">Here is where the Solution Consultant come in the picture. They are the people who do the chunk of the work for you. Think of them as the people who will do it for you or find someone who does it for you and then get it done. A CTO's true friend. </span></div><div style="text-align: justify;"><span class="Apple-style-span" style="font-family:georgia;"><br /></span></div><div style="text-align: justify;"><span class="Apple-style-span" style="font-family:georgia;">A solution consultant is the entity that gets hired the moment a CTO starts thinking of software implementation. The CTO is now, least bothered about who, how or what. </span></div><div style="text-align: justify;"><ol><li><span class="Apple-style-span" style=" ;font-family:georgia;">All that he/she knows is that a vendor has been finalized (of course, based on careful introspection only). The difference is that, now the CTO has access to a wider range of solution providers. Doing the market research and finding the best vendor is the job of the solution consultant. The CTO will now know that a vendor has been finalized and the grounds on which it was.</span></li><li><span class="Apple-style-span" style=" ;font-family:georgia;">The solution consultant will then track the software development life cycle phases with the vendor. The responsibilities to finalizing the time estimates, approve the cost, technology decisions, etc. still lies with the CTO. But now the CTO doesn't have to sit and figure it out. The architect does that for him/her. </span></li><li><span class="Apple-style-span" style=" ;font-family:georgia;">The change requests, bugs and their fixes, software licenses and agreements, etc. are kept track of, in detail.</span></li><li><span class="Apple-style-span" style=" ;font-family:georgia;">The solution consultant worries about the implementation of the new software and its integration in the existing architecture after the implementation. </span></li><li><span class="Apple-style-span" style=" ;font-family:georgia;">While the system is being deployed on the UAT, the solution consultant arranges for the test cases. The business users perform the UAT based on these test cases. </span></li><li><span class="Apple-style-span" style=" ;font-family:georgia;">And much more...</span></li></ol></div><div><span class="Apple-style-span" style="font-family:georgia;"><b><span class="Apple-style-span" style="color:#660000;"><u>6. WHO ARE THEY? WHERE DO I FIND THEM?</u></span></b></span></div><div><span class="Apple-style-span" style="font-family:georgia;"><b><span class="Apple-style-span" style="color:#660000;"><u><br /></u></span></b></span></div><div><span class="Apple-style-span" style="font-family:georgia;">They can be absolutely anyone; either an organization that specializes in offering these services or individuals who do the same.</span></div><div><span class="Apple-style-span" style="font-family:georgia;"><br /></span></div><div><span class="Apple-style-span" style="font-family:georgia;"><b><span class="Apple-style-span" style="color:#660000;"><u>7. WHAT IS THE POINT, I AM TRYING TO MAKE?</u></span></b></span></div><div><span class="Apple-style-span" style="font-family:georgia;"><b><span class="Apple-style-span" style="color:#660000;"><u><br /></u></span></b></span></div><div><span class="Apple-style-span" style="font-family:georgia;">All the CTOs out there, before you decide to implement a software solution yourself, explore this option. Whats the harm? What do you have to lose? You were going to work hard anyways ;). Get it done from someone else for a change. </span></div><div><span class="Apple-style-span" style="font-family:georgia;"><br /></span></div><div><span class="Apple-style-span" style="font-family:georgia;"><i>[All the above view points are my perceptions based on a very fruitful career in software industry. I have seen Sales Directors, CTOs, CEOs, etc. actually throw money (not just out of choice but more out of compulsion as well) at anything that resembles what they need as a software implementation and the software companies actually milk them dry for this. </i></span></div><div><span class="Apple-style-span" style="font-family:georgia;"><i><br /></i></span></div><div><span class="Apple-style-span" style="font-family:georgia;"><i>More often than not, the customer needs 'x' set of requirements. But in their search, the customer ends up with a vendor that has a product with 'x-y' set of features. The rest of the features are charged heavily as a customization</i></span></div><div><span class="Apple-style-span" style="font-family:georgia;"><i><br /></i></span></div><div><span class="Apple-style-span" style="font-family:georgia;"><i>I, hence, decided to educate/warn the concerned about the ill effects of such an approach. This is my first (very first) blog on giving something back to the community. You can expect more.</i></span></div><div><span class="Apple-style-span" style=" ;font-family:georgia;"><i><br /></i></span></div><div><span class="Apple-style-span" style=" ;font-family:georgia;"><i>Kindly provide me with your feedbacks.]</i></span></div><div><span class="Apple-style-span" style="font-family:georgia;"><br /></span></div></span></span></div></div><a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgIZ7XbF0bYtEyb8t9G_TWya915iID-0YFYLQ2yboUJ6SlTEIFoRTWRkHBHa7BCGG-arYd1jjBLPkS5MsK5dmJ-wNP6i-EuF4mxag9BlNaxRBjwWcQuSaCV-QpQxM45vUt6rfsuW7ap-dii/s1600-h/business_process.PNG"></a>Anonymoushttp://www.blogger.com/profile/12651125370890137864noreply@blogger.com0