Tag: best practice

Categories
blog

Open Group Conference 2014 Bangalore – Where is EA now ?

opengroup

Was at the open group conference at Bangalore and spoke on “Enterprise Architecture and Keeping your business relevant”. Was off to native and could manage to attend the second day of the conference at Phillips Innovation Campus.

Initial Talk was by Jason Uppal on how EA was used to solve problems in the heath care industry and his experience in the same with some case studies.

Some interesting perspectives on initiatives from the Open Group to take Togaf body of knowledge to colleges along with Computer Society of India and an effort to popularize it apart from being used by the industry alone.India ranks third in the list of Togaf certified candidates and increasing year on year. This was briefed by James of the Open Group.

EA and the Developing World

Far away countries such as Finland and Brunei are also adopting Togaf and there is growing list of developing countries such as Mongolia  which also is adopting Togaf for overall streaming lining of IT services. This was presented by Vish Vishwanath of CC and C solutions.He also walked through the penetration of EA in these markets and how EA can significantly be used to solve newer technology adoption issues. Developing countries will have to go through the same curve where EA can play a good role in packaging and getting your business / IT strategy right. This market is hugely untapped and really be a good case in point to explore and would most likely a candidate where future success stories would be crafted. 

Keeping Your Product/Solution Relevant

Spoke on using EA to help keeping the business relevant. Touched upon how a reference architecture helps create a north star to follow. How a large company can stay agile and make quick turn around as it is said making “Making an Elephant Dance”. Most large corporations are now focusing on learning this key skill. Gave a brief presentation with 18 list of TODO’s for a company (product/solution). Irrespective of the size of the company the ability to dance to various market and customer tunes is what helps it stay on top of the curve. The presentation details are shared here. All of the slides have 18 TODOs listed ( in no specific order ) and each category needs a deep dive into what can fit well for an organization specific context. Overall a handpicked set of initiatives that help a product or a solution to be relevant in today’s times. Even implementing a few of these initiatives to a reasonable degree of seriousness can create the hockey stick effect on your annual performance report , which is the last slide of the presentation. 

opengroup_2014

Commoditization of EA

That apart there was a talk on how EA is being packaged and off shored an IBM perspective by Sreekanth. This dealt with the issues of putting solution architecture work miles away from where it is being consumed and how technology has progressed in making this happen. How customer’s are now adopting this mode of delivery and look forward to having a robust process framework around this to help with getting predictable and estimates for the same. Ideally they would like to have better control on the work pieces assigned to the team off shored to and be able to estimate and bill accordingly. As a lot of things are new on this front as always it takes sometime to stabilize things on this front. Have come across SAP and other vendors opting for a packaged implementation points sort of a things which is like a work break down structure for your activity at customer location. World is indeed getting flat including off shoring innovation work  till the point that you are not sure your idea is going to fly. In which case more clarity emerges and all trial and product pivoting also is getting off shored.

There was a talk by Hari from TCS on a case study of who they used Archiemate to map customer requirements and showcase value to the customer end user on use of the same. This is a neat initiative that is picking up momentum on tying together business and IT together. UML is for techies and not all business nuances can be conveyed using the same. The business folks are not UML friendly and a free format diagramming visual standard such Archiemate is useful in helping bridging the gap between the two.

Disconnect between Archiemate and Togaf : For people entirely new to these they need to be treated separately and does not pose a problem. For folks coming from the Togaf world there seems to be a missing perspective ( data ) which archiemate has across all the layers and gives primary prominence to Business , Application and Technology at least in the views. The data part of the details are implicit across the visual representation of Archiemate and quite embedded as a part of Business , Application and Technology instead of being treated separate. Quite understandable as bringing data architecture at a overview level can pose the trees get coverage instead of the forest. Anyway it is a step to bridge the divide between business and IT. Have heard about how this standard is helping many approach architecture diagrams without being overwhelmed at the outset with semantics of the new standard or other intricacies of UML which for a person from the business would be hard to scale upto. Certain regions have a good adoption of this standard and certain countries are ok with BPMN / UML or arbitary or No UML as it is referred to where every organization creates a standard that suits its needs the best with legends etc.

A weekend well spent discussing things that matter and can change lives and our part in the same.Attending conferences always keeps you relevant and of course helps one in keeping abreast of what is happening around.

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

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

 

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.

 

Categories
blog

Best Practices are often not obvious at first sight…

bestpracticesarenotobviousatfirstsight

 

Most often best practices are hard to follow and often questioned on the rationale behind the same. Recently I had my car serviced at the car vendor’s service outlet. Always there was a question that lingered in my mind on a card board box that gets placed at the top of the car indicating the ticket/token number indicating the car service ticket number . This is opposed to the bike service experience of mine , at the bike service station the guy attending the customer always does this by means of scribbling the number by means of a wet chalk. Used to wonder why the car guys do not follow the same thing and why do they resort to the card board box on top of the car with a number on the box. Used to think that this was something only my car vendor service team followed. More recently went to another car service station from an another car vendor.

Continue reading “Best Practices are often not obvious at first sight…”