Category Archives: Blog

Open Group Conference 2014 Bangalore – Where is EA now ?

Leave a reply

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.

A Multi-Hued 2013 is behind us – Welcome 2014

Leave a reply

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.

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

Leave a reply

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.

SOA is not the same as Enterprise Architecture

Leave a reply

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.

Centralize Interoperability and Decentralize Implementation

Leave a reply

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.