EA - Enterprise Architecture in Action

Happenings in the recent weeks have turned many tables and raised many eyebrows. It has been a crash from fantasy to reality for many organizations in the need to make IT real, effective, cheaper, faster, cleaner. Organizations are in a hurry to get unproductive assets, esp Cap-ex, off the books.

This is a big change for suite vendors who have positioned their products to “capture” the solution space by selling software in an integrated package form, wherein many aspects aren't necessarily being utilized.

This is especially true in the case of SOA, where there is no hurry and sometime no need for components like registry, repository, accelerators, test suites and the like. These components unlike the ESB and messaging components, the WSDL, workflow and rules components may or may not be implemented. However, organizations who have bought suites already use infrastructure to run, monies to license, Op-ex (train and maintain) seemingly unused software. Points to consider

• While purchasing a suite may seem economical in the short term, it is almost always more expensive in the long term. It also ties you into vendor specific technologies which may or may not be in the best interest.

• Application and system portfolio rationalization does not impact IT assets bought in the last 10-20 years. It should be in place now both from a CFO function and a Governance function for current and future purchase plans. Stopping it at the door is cheaper than finding ways o decouple it

• Take a multi-pronged approach to your implementation  and adoption strategy

• Invest in creating a current and future reference architecture or pattern that will create a common understanding of direction across teams and portfolios.
• Decide whether you want to go top down, bottom up or middle out. Middle out allows you to move many current investments into active strategic projects with a quicker time to market, a ready business case and better acceptance
• Break up the development tracks and owners based on the lifecycle of the component
• ESBs normally needs to be part of the corporate infrastructure and can follow the waterfall or iterative software development lifecycle
• Creating granular web services can be an agile or iterative approach based on the nature of business. E.g. media and publishing is likely to be more agile compared to banking or insurance which tend to have more iterations and luxury of time.
• Sustain an IDE which is common across the internal and external (vendors and partners) teams. Create an SDK which can be used to publish and facilitate the development through reuse v/s governance
• Testing – automate it for standards and interoperability. There are several tools for this once the functional test is done
• Instead of full fledged governance of reuse – institute Data Stewards which ensures better data quality and source systems and at the same time brings in essences of governance but with tighter and more practical controls
• A little extra planning - invest in loose coupling, with SaaS, cloud computing, BPO and virtualization becoming progressively mainstream.
  

While this is by no means a comprehensive list – it is the essentials and a starting point from experience – it would be wonderful to hear other readers, strategists, architects and practitioners’ experiences.

Posted by Sohrab Kakalia at 8:32 AM | Permalink | Comments (0) | TrackBacks (0)

- Amit Jnagal, Senior Technical Architect, Infosys

In my last post, I talked about the movie My Cousin Vinny and the lessons it held for Architects about sticking to the basics, understanding your customers and understanding yourself.
In this post, I am going to look at The Pursuit of Happyness (Year of Release: .2006; Director: Gabriele Muccino; Our Architect: Chris Gardner played by Will Smith; Architect's Character: Sales Man turned stock broker who know how to dream big and keep it going).

‘The pursuit of happyness’ tells the story of the trials and tribulations of semi-successful sales man for whom every day is a struggle. The essence of this movie is how to dream big and manage it along with the daily struggle. We usually get too involved in the tasks that are assigned to us and find very little or no time for stuff that matters outside assignments. Very few other industries, other than ours, have employees who are up to speed with the usage of the term ‘work life balance’ and how it affects them.
One lesson that we architects can pick up from this movie is to dream – dream big and pursue them. I have been asked this question a few times by different mentees – “What is the end goal for an architect’s career? Or If I pursue the career path of an architect, where will I be 10 years from now?” Let me take a stab at this question in context of this movie. The end goal of an architect’s career, or any other career for that matter, is to pursue a dream – something that makes you happy, something that sets you free.

For some people the dream is realized when they become their own boss, head the technology think tank of an organization or make it to the board of directors of a company. Yet, for some others, dreams are realized when they invent something, write a book, or teach something. It doesn’t matter what your dream is, as long as have one.
I believe in the saying – “Dreams are work in progress”. Make it grand, make it big and keep it close to your heart. Don’t forget to remind yourself regularly that whatever you are doing today is just a path to realize your dream; it is not the end game! To pursue anything worthwhile, you need to dream it first.

The end goal of a career path is when you have realized a few big dreams …

Posted by Guest Author at 6:14 AM | Permalink | Comments (1) | TrackBacks (0)

We just completed our 3rd annual survey on Enterprise Architecture. The survey brought out some very exciting findings, as well as some which we see as potential gaps or blue ocean. 

One of the key findings is that participants of the survey saw Enterprise Architecture as a capability that was core to their business and inherently part of their organization's crown jewels. However, given the daunting set of activities that most Enterprise Architecture functions have to execute today, the opportunity to work with ESPs and enlist them to execute some of these activities is real. In other words, some activities (the more tactical ones), can be outsourced to a strategic vendor partner.

Gartner has reiterated this in their research note (subscription required to view the note) this week.  It is comforting to see that they see the same conclusions from the data as we have - there are specific activities that one can engage ESPs on, but don't wholesale outsource the capability. 

We have engaged with multiple organizations to execute select EA activities in a collaborative model,  with the objective of ensuring that the EA function focuses on core activities such as business engagement, business alignment and strategic IT planning.

We are therefore seeing truly mature EA functions recognizing what is core vs context in their operating models and leveraging partners as necessary, to deliver even more business value cost effectively.

Posted by Sohel Aziz at 9:34 AM | Permalink | Comments (1) | TrackBacks (0)