Category: blog

Categories
blog

The loser takes it all , failure is so welcome

failure_not_an_option     

Keeping Failing But do it Fast – Projects / Pet Agendas and Companies 

No option to fail , serious problem. Not failing not quite true anymore ? …This is sounds quite a ridiculous statement more like saying that if you wish to live forever then you should be prepared to die any moment meaning for a cause then you become immortal and then you live forever. The only way to remove a thorn is with a thorn. Does not mean get pricked by a thorn to remove one. What it means is if you the quicker you fail the faster you realize why you failed introspect and move on. Yes inspect why you failed and move on. What this goes on to state in so many things in different facets of life.

Software Projects : You have a mandate from product management on some feature that looks cool in the market and have been asked to roll it out without questioning authority. This then leads teams to prototype it and then check what are the pain points involved before you can say it looks ok to go ahead or not ok. This means you have imposed an increment of work unit which is short time boxed and you come back with your conclusions or state what is possible and not possible in black and white. At times the shiny new thing on the tools available might force one to think that it is the way to product stardom etc. But once you have developers dig their claws into the library or framework it can really reveal whether the framework really promises rapid application development or it is just another cool thing but not so cool when really played around with. Once you get used to failing every now and then you get to learn a new way of handling things in small iterations. This reinforces one to believe that failure is after not all bad in fact we are now more knowledgeable with all our combined failures put together. When someone says we trying out that thing in the market you know what that means and know your way around it . Fail fast is the new world order. It was always like that we never noticed it enough. So all such truth lay hidden reveal themselves to us when we move around try new things and fail , yes fail. Once you know it then the other side of the coin has success embossed on it . The trick is to identify it first and get it right. Know you have failed and that too fast. Do not worry about the project estimates going for a toss , put them with the knowledge that there is going to be 20 % this way that way to it. The message is don’t aim for perfection keep failing and refining.

Pet Projects : Read some where that what ever was in your mind a while ago is now on TV and leaves you thinking that “Oh Oh that was my idea for my pet project” . Do not keep them so bring them out do what you can do to flesh them out bring them to reality else they remain pet projects. This principle also translates it into a fear principle. The guy who has failed first becomes more successful. School dropouts can only create a Microsoft , Facebook or Oracle. Do not keep anything a pet project is the moral here.

Companies : With everything lean and mean a company now unashamedly keeps on revising its mission statement from time to time and does not think twice before changing course many times during the day instead of months or years. Earlier you needed the big consulting companies to say where you are heading and when to turn left and right. Now most companies seem to follow the agile way of doing things and shorter project iterations reveal what we need to do eventually with the product , roadmap etc. So when the failure principle is inculcated into teams , individuals and then the company culture then it becomes easy to drop your opinionated theories and see for yourself in short cycles and tailor your turn around quickly.

What it means that the more agile you are more prone you are to repeated failure. Stay agile welcome failure in leaps and bounds.

Categories
blog

Training By eturnti on Aug 10 -11 2013….

facebook_banner

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 ladder in your organisation can augment your skills 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.

Past sessions had the following mix of people attending this training developers,leads, managers,architects, business analysts , consultants working on IT projects, directors and people who are , going to be part of enterprise projects and wanted to know more on how they are managed and executed.

Following are  some of the aspirations of the candidates who attended this training in the past.

1. How are EA projects managed ?

2. How are EA metrics captured , benefits measured and calculated ?

3. What are the EA frameworks and how are they used and applied in principle ?

4. How is this applicable for product development ?

5. Justify the usefulness of EA and measure overall effectiveness of an EA program.

6. Apply these principles to IT and infrastructure projects.

7. Want to lead a team of EA architects and manage an EA project .

8. Usefulness of Togaf and Zachmann and how to apply them to real life projects and derive value. Understand these frameworks and their relevance in setting up an architectural practice.

9. Convince management on architectural best practice and able to contribute to architectural decision making in the organisation.

10. How can we keep EA technology/platform agnostic ?

11. EA and agility where do they mix and match ? Is it really feasible ?

12. How to keep EA projects in iterations well managed and accountable ?

13. Want to know what this buzz EA is all about and what does it mean as I am currently doing architecture work.

Become good at what you are doing, impress your managers,coworkers by attending this course and finally add value to yourself.

Drop a mail at asketurnti[at]eturnti[dot]com to book yourself or click here.

 

 

Categories
blog

Testing game is about to start are you ready ?

areyouready

With the development team’s task over now the task passes on to the QA which is a critical leg in the project. In fact they are the last sentinel on the way to the software trying to make or break its way into the release shipment. While QA could work hard to find and unearth bugs and issues which otherwise might lie hidden under the labyrinth of the product / application. It takes more than just skilled developers doing their best not to plug in errors into the system.While find bugs , code reviews and umpteen number of best practices would ensure that we produce a great piece of functionality or product which is always ready to be shipped the day QA bless it.

Testing a challenge a skill a craft and not something that is easy to do. It is a forte of a chosen few who do their best to go under the hood and look for the spanner left over post the tasks. It is like a doctor who would have performed a successful surgery but left a knife in the patients body. Testing if done right can trap these defects and help plug these issues.

From a tester’s standpoint what would be important ?

1. Many a times a viewpoint/view that he is looking at is not available in document format anywhere in the organisation.

2. No proper handover of what goes into the software if the developer did his stuff and left early to catch the friday nights bus.

3. No diagrams to illustrate what is that has changed in the organization big picture. He is told things like “we have improved security in the system now”. What does this statement leave the tester with unless told what was really introduced as a part of the fix or change.

4.Does he understand what needs to be tested and does he have the tools.

5.Does unit testing/TDD cover what is to be certified. Or do you always need a full product end to end scenario testing.

6. How much of automation do you have in the system ? Are the test cases all automated and effort being made to check if the code coverage is 80% and above. Do we need to up this number ? . Are we getting false positives ?

7. Does our code coverage make us happy whereas there turns out there is always some boundary condition that missed our attention?

8.Do you have a proper architectural artifacts documentation strategy where QA can go look at it and figure out from time to time where the product is heading ? Most often we have it was last updated when we went for that team outing.

9. One of the ways the product gets to have a feel that all is well in the system is a reiteration their documentation and diagrams are updated and understandable by one and all in the system. This mechanism needs to be continuously followed for everyone to sub consciously starting to feel that our mechanisms are what it should be. If not there we fix them when found. Any other feeling here will not reinforce the “right way” among people.

UML is understood by techie crowd whereas we need to have a mechanism for ensuring the business,functional folks and non technical folks also understand the system to touch/feel/breathe the system and own it as much as the developer who put pieces in their. All of these need strong mechanisms for documentation and diagramming/some kind of non ambiguous visual representation of the system/product.

Go choose your diagramming strategy and be ready for any challenges on your way. It is always better to document things even for preparing for agility. On one hand as we always prefer working code than elaborate documentation , it is equally important to have a proper mechanism in place that works for you. That is where the question of just enough comes into play go for just enough documentation and visual representation.

Ultimately software delivery is a close knit game where all need to play their part and not simply passing the baton from one team to another.

Categories
blog

Project in Auto Mode (Scrum) . What do I do as a Project Manager ?

roleofproject_managerin_scrumMost often companies embracing agile practices go through different moments of self truth and stories of shifts in thinking and the experience that can be termed as close to realizing your true self. All the while having been used to a set way of doing things turning agile is almost equal to turning a new leaf in your life book. It needs very strong management involvement and commitment from all the stakeholders to make it a success. It is a given that people understand what this means and act accordingly to achieve the end objective. 

Scrum teams are self organizing : What does this mean , it means they know what to do how to do and how much to do in a particular iteration. Lets keep this simple for now meaning we all understand the basics of scrum  at some level that it is refined quicker and leaner and meaner version over your traditional project management practices. Now there are various key role in the scrum iteration or sprints as they are referred to. As per scrum principles there exists no project manager with a title at least in formal terms. What do existing project managers in the system do ? Go find a hobby of their liking and pursue it or go on a short sabbatical and be back when required.This again depends from organisation to organisation how the role is defined and what roles a manager typically plays over there.

Project Manager in smaller organisations

If it is a small organisation or setup then a project manager gets to play the role of the scrum master or product owner. He/she clones himself into the roles of a scrum master or product owner and plays his part. Ideally you should not mix and match product owner and scrum master as the focus each role has is different. Here again it depends on the maturity of the organisation or the luxury of having dedicated roles if the team size is considerably small. There is no set rules here just because your into agile or scrum does not mean your are fully agile or aren’t. Companies take time to achieve this state over a period of time and it is not overnight.

Scrum Master : Involved with the team coordinates with external parties and ensures team’s voice is heard well outside of the scrum discussions , is responsible for the outcomes , resources and people. He is like a project manager turned well wisher of the team who is not seen as someone who can be career limiting if you cross swords with. A refined project manager with strong head balanced over his shoulders knows where to give the team its due and is finally accountable for it.

Product Owner : Interfaces with the team for things outside of the team as a single point of contact. Defines the product / project scope , prioritizing the items of the product backlog. What gets done now and in future iterations? Speaks for the end user and wears the customer’s hat.

Scrum Team : We are the new kids on the block who do not need to be told what to do. Everyday we meet and exactly figure out what each one fills up his plate with. We do each share others burden and know where to meet each day and say hi , hello to all in our team at a fixed time thanks to scrum else we would be brooding next to our monitors pretending to be immersed in work having no time for meager social protocols.

Project Manager in bigger organisations : Here the role of a project would be that of managing expectations of external stakeholders , planning resources , budget , team transitions , resource transitions, talking internally / externally to other teams and interfacing with them to create a organisation best practices / repository of information. Appraisals for the team in coordination with the scrum master.Taking receiving feedback from resources who are now not directly reporting etc. There are various other things he could be involved in such as following up on release closure activities of previous cycles ( agile or non agile as the case may be ). So simply it means that every time there is a change people get pushed and moved around and challenges everyone’s status quo. Accept the change move ahead all get to play there part and scrum is not the red revolution around the corner once things have stabilized and the initial resistance melts down.

What is there for us in a scrum / agile environment ?

In fact all of this requires the entire team / managers to be geared towards preparing for what is expected of their teams. Mailers , tech talks and other organisational propaganda , brown bag lunches all help here. In fact the question for all would be what is expected of oneself as we go through the churns in a scrum or agile environment.

 

Categories
blog

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

RB-JumpingHurdle

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

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

Create your destiny :

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

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

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

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

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

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

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

 

Categories
blog

Create your product roadmap radar

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

Build your product roadmap/radar 

product_radar

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

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

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

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

 

Categories
blog

Summary Execute Execute Execute – Message from StartupCity2013

startupcity2013

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

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

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

Arun Jain ( Polaris)

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

Padmaja Ruparel ( IAN Network)

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

Balaji Parthasarthy  ( SnapFish)

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

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

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

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

Meet the VCs 

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

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

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

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

 

 

 

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

Learn to say No and You become an Yes Man

Firstly say No to SQL

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

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

Why No SQL Maps fits the Cloud Model

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

Why JSON is becoming the standard sought after ?

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

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

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

Secondly say No to UML

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

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

Categories
blog

Enterprise Architect is a Business Man / Trader of wares

EA-businessman

Enterprise Architect is a business man meaning should understand the cost implications involved in running software enterprises end to end. He should be able to wear a BA’s hat when required translating requirements and clearing road blocks which are found at the business/IT intersections. He should be well versed with all forms of business analysis and be able to separate the grain from the husk. So an EA can be someone who progressed from a BA to an EA or became an EA via other routes. At the core of an EA’s skill set is someone who knows the business of running an application / product or an Enterprise using IT.  If you look at how EA has evolved over the years from being a core technical person to someone who bridges the gap between business and IT. 

Most EA are accountable for couple of million in the Project/Product’s outcome. So although good techies can take a product/project to a level it needs business focus to be able to focus on the results of the business outcomes. You can develop a great product using technology but the point of inflection where it meets end user needs and the market can be well understood if the business needs are well understood.

An interesting technology creation is twitter which enabled to let people talk publicly about their cats and dogs. Initially it was thought to be an useless creation having no immediate business value but it has as its core of connecting people at a scale unimaginable in history. The 140 chars is the new low and high as well.

EA should know the business side well …among other things