EA - Enterprise Architecture in Action

- Murteza Salemi

In the IT industry, from time to time, we hear terms and notions that carry special meaning within the industry. Evergreen is one of them. One of the dictionary definitions of 'evergreen' is something that remains perennially fresh, interesting, or well liked. But what does evergreen solution or technology means within IT context?

Simply put evergreen can be translated to ever relevant. In other words, a solution that has the capabilities to sustain and adapt to changes, and to continue to re-innovate and evolve through service capabilities over time.

How do we build an evergreen solution?

Is there any technology, architecture or process that can provide us with such a solution that remains ever relevant during its operation and life span within an organization?

In my opinion, no technology, architecture or process can provide such an evergreen solution that can meet today’s ever changing requirements and business needs; unless you engineer it to do so and consider all the enablers i.e. technology, architecture and process that help to achieve this goal.

Providing an evergreen solution is a subject that has many facets and IT practitioners have expressed their views on it and suggested many approaches for it. Some of these view points are as follows:

• A clear business strategy will lay the path for creating an evergreen solution by applying principles such as aligning business processes to business goals, etc.
• Mainframes have historically been there and will always be there hence it is “Evergreen”
• Evergreen solutions can be built by defining and governing an enterprise technology architecture that promotes standardisation
• An evergreen solution means 24/7 system availability
• An evergreen solution is to architect for change and consider content, process and people elements and not just the “technology” by itself
• SOA powered by a governance framework provides for a sustainable evergreen solution that is flexible and adaptable
• SaaS is the way to go for delivering an evergreen solution, as it is incumbent on the service provider to “keep it evergreen” i.e. relevant to changing business objectives.
  

Each of the above approaches has its own interpretation of the evergreen requirement for a solution. Although there are different approaches, there is still some commonality between them as the end result is the same for all these approaches - i.e. building a solution that can sustain changes and innovate over time.

Posted by Guest Author at 11:18 AM | Permalink | Comments (0) | TrackBacks (0)

One of the fundamental things about SOA that every organisation needs to understand is where they stand today before starting the SOA journey. This would quickly give an overview of the organisations readiness and maturity for the SOA journey. Organisation should start finding out the answers for few basic questions:

• Do you have enough buy-in from Business, IT and other key stakeholders and of course the right business case to adopt SOA?

• Do you understand your (organisation/BUs) current SOA maturity and opportunities for improvement?

• What does it mean when it comes to adopting Service Oriented Architecture (SOA) – Organisationally (People, Process, Governance) and Architecturally? Please refer to my earlier blog – Making Your SOA Journey Successful

• Do you have enough appetite to invest on SOA and wait for the benefit to come-in? SOA can not be achieved overnight – it’s a long journey.

Understanding the real health of the SOA of any organisation is a two step process.

• Pre-assessment

This should really focus on the high level strategic directions at organisation level rather than getting into nitty gritty of actual organisational SOA capabilities. One needs to find out if the basics are in place from SOA point of view

• SOA Business Case: How SOA is going to reap benefit for business. Having strong case to improve only IT is not big enough for SOA
• Understood the benefit of SOA by the stakeholders: Tangible and intangible
• Have buy-in from all the key stakeholders
• Is there a SOA strategy at Organisation/BU level

Based on the findings of the pre-assessment, a decision to move ahead with the next phase (full blown Assessment) would be taken. In case of missing business case and lack of buy-in from the key stakeholders – the focus would be to create a business case and at the same time institutionalise the benefit of SOA within the enterprise. Without getting these two in place, there is no real benefit of trying to understand the current SOA capabilities through a thorough assessment.

SOA Maturity Model

View SlideShare presentation or Upload your own. (tags: soa maturity assessment service-oriented archite...)

• Assessment

Once you have done the preliminary checks and made sure the organisation have a business case for SOA, all the key stakeholders are in sync and understands the benefit of SOA, it’s time to go and unearth the goods and bads around SOA within the organisation. The assessment goes deep inside into your capabilities around the following dimensions and identifies gaps followed by a set of recommendations to achieve higher level of SOA maturity.

• People
• Process
• Architecture: Includes Business, Application, Information and Technology (inline with TOGAF)
• Governance
• Services
• Engagement, Delivery & Operations

At the end of the Assessment phase, along with the key findings and recommendations, SOA Maturity of the organisation is defined using Infosys’ SOA Maturity Model (please refer to the presentation).
 
With targeted recommendations for improving your maturity level, the Infosys SOA assessment framework/tool can help you unlock the full value of SOA.

For whole set of SOA offerings from Infosys, you can visit http://www.infosys.com/soa

 

Posted by Shubhankar Sumar at 6:57 PM | Permalink | Comments (1) | TrackBacks (0)

EA has long been seen as time consuming to implement, difficult to get buy in and govern. Do organizations really have the luxury of choice? The cost of not aligning and optimizing is bringing systems to a grinding halt, not because of lack of CPU power, but dwindling funds to manage them. Very similar to the fuel crisis and need for better efficiency or alternative energy thinking, the time is ripe for efficient EA. What EA also needs is a dose of lightning up. EAlite anyone?

With so much in the works with B2B, B2C, G2B (government to biz) taking center stage fueled by industry standards like ACORD (Insurance),SID (Telecom), FIXML/FPML (Finance), HL7 (Healthcare), etc, the time is ripe to tie the standards knot and adopt universally acceptable baselines. SaaS and Cloud computing too will get easier to adopt.

Next month’s Gartner Enterprise Architecture Summit in Las Vegas (Dec 10th-12th) will be one to watch. The real value of EA and its agility will be put to test in the next few quarters and years. How it ties back to this month’s Master Data Management Summit in Chicago (again by Gartner) will be even more interesting given that the set of analysts have very little overlap

Posted by Sohrab Kakalia at 9:11 AM | Permalink | Comments (3) | TrackBacks (0)

EA enabling strategies and principles should be specific to each enterprise; And is governed by its business strategy by a large extent.  In recent times, some common EA enabling strategies, in one way or the other, have influenced EA more than the others. This entry is an attempt to identify some of those more ubiquitous and important ones, that may further be elaborated on case to case basis.

Form an Architecture Governance Team
 

• A central team constituted with representation from stakeholders across the organization, should govern the planning, evolution and implementation of an Enterprise Architecture framework
   
• Architecture should be well thought through to meet the common goals of all stakeholders.
   
• The central team also should play a key role in establishing products, design and technology standards
  

Information Architecture should be done across systems

• Information is Business Asset. Decision-making requires information that exists beyond the boundaries of individual systems, departments or agencies. Hence information models should not be limited to system boundaries
   
• Treating data as a business asset increases the importance of identifying integrity and relevancy of data and improves data quality access
   
• Information should be classified. Appropriate security policy, DR policy should mapped
   
• Enterprise Security principles and standards must be identified and applied uniformly across all projects

Identify and implement common services for the enterprise

• Common services provide the basis of a truly service oriented architecture. Common Services will be responsibility of a inter-department ‘shared-services’ team
   
• Care should be taken to make the low-level common services independent of each other
   
• Common Services should respect the common information model as closely as possible

Factor in scalability

• Key aspects of scalability are volume, concurrency and functionality. Decisions on the underlying technology infrastructure should factor all these dimensions

Plan business continuity orientation early

• Assess availability requirements of the systems based on business needs. Overstated availability requirements can cost dearly. On the other hand, not considering business continuity with adequate seriousness can mean disaster for the business. Hence, appropriate reliability and disaster recovery strategies are essential to overall architecture planning

Reduce TCO

• Cost of compliance (development, implementation, maintenance, training, and infrastructure) should be balanced against technology considerations (scalability, flexibility, ease-of-use) in decision-making
   
• System consolidation and rationalization should be aggressively pursued aligning with the Business and IT Strategy
   
• Adherence to widely adopted open standards reduces obsolescence risks

Consider shared vs. owned and virtual vs. physical

• An increasing number of services today can be sourced from outside the organization, including hosted software, data, and maintenance of the same
   
• Outsource operation and processes, maintaining strategic architectural decisions
   
• Also, consider virtualized hardware platforms those can be scaled up or down on demand

Posted by Santanu Dey at 6:17 PM | Permalink | Comments (0) | TrackBacks (0)