Good EA Ideas...

For architecting the enterprise, we need good ideas to mature, evolve, and innovate. And good ideas can come from literally anywhere, so we should not limit ourselves to looking for them in-house, in our industry, locally, regionally, or nationally. Good ideas are global and we need to reach out for these ideas, adopt them, and make them our own, regardless of where they originate……………(read more)

http://usercentricea.blogspot.com/2008/07/global-innovation-and-enterprise.html

By Andy Blumenthal

EA’s Value Proposition

“The value proposition of the EA process to the organization is a difficulty that the industry is struggling with right now. Most of the value measures I have seen applied to EA are really just a re-hashing of traditional business program performance metrics. The problem is trying to attribute economic value directly to EA based upon programmatic outcomes that occur years later and that can be influenced (positively or negatively) by many other factors outside of EA.

I would be interested to find out has anyone either developed, or come across, relevant Key Performance Indicators (KPIs) for EA?”

--Jelena Roljevic

Instilling EA – A Perspective

Enterprise Architecture (EA) means many things to many people – Data Architecture, Application Architecture, Infrastructure, Shared Services, SOA. For me EA is an evolving blueprint of an organizations current and future state with a clearly defined transition strategy.

What definition is correct? Well they all are. Any philosophy that encourages consolidation and integration, and one that adapts to the ever changing business and technology environment and mission of an organization is EA. This philosophy goes beyond frameworks, tools and approaches. It effects change both culturally and organizationally. When instilled correctly, EA will turn a fragmented, silo’d and decentralized organization into an agile, flexible and efficient one.

Cultural resistance is probably one of the primary combatants of EA philosophy. Fear of losing ownership and control of our domains such as security, resources, data and reduced funding. So the big question is do people “Get It”? EA is enterprise strategy aligned with business goals, aligned with technology assets, and all combinations there of. Think of an engine and the sum of its parts. If we remove one component the engine ceases to work effectively - if at all. This is EA and how it needs to be communicated.

For organizations to emerge from EA philosophy/mandated EA or “shelf-ware” EA to “actionable” EA, successful organizations are taking the “segmented” approach. The segmented approach identifies “low hanging fruit” where an organization will get the quickest win, resulting in buy-in and consensus across departments and agencies. In this way results can be measured and acted on. Some examples include Capital Planning, Shared Services and lines of business.

In summary I will share a story of one of my clients’ EA strategies as an example to combat cultural resistance:

Civil agency (Agency X) is typical in its environment – twelve stove pipe, silo’d departments. Agency X is embarking on a very large shared services program - consolidation of its IT infrastructure, requiring a significant capital investment. Agency X will be utilizing the Federal Enterprise Architecture Framework (FEAF) as its foundation for the program having already utilized the same to align with OMB mandates and in developing out its EA program.

In support of this Shared Services Program the CIO’s office developed an education and communication plan. This effort defined how each department would continue to run autonomously, yet for current and future business needs, the Enterprise Services Catalogue should be utilized in supporting their requirements. This approach pleased the respective department heads as they felt ownership and control was being maintained.

The beauty of this model is that whilst thinking they are operating autonomously the departments are actually aligning themselves to governance and standards, collaborating, becoming agile and flexible in their operations, supporting the creation of a more efficient environment, aligning with enterprise strategy and mission goals and providing a better service to their citizens. A simple approach effecting significant benefits.

-- Nevvar Hickmet

EA is needed now more than ever

EA is needed now more than ever - but with two caveats i) that EA must evolve, and ii) do firms recognize the EA function by name as a way to solve their increasing business and technology challenges.

Lets use an very recent, publicised, well known and very signifcant example to illustrate.
With SAP just announcing this week the acquisition of Business Objects and Business Objects themselves just recently launching an on demand service that is poised to change the BI landscape - the last and traditionally recognized safest haven of vendor led application and platform stability SAP, has just literally been blown to pieces. The safe haven - for an organisation seeking to delegate EA to the vendor community, the strategy of reliance on a Vendor to provide platform stability and interoperability no longer exists.
With this destruction - beyond doubt - EA is now becoming a strategic imperative for all companies - whether it goes by that name or not - companies will need to adopt an EA capability - evolve an EA function in some shape or form. They can no longer rely on Vendors - if they ever could.
With the volatility of the major application and platform vendors solution stacks going through massive changes driven in large by their own need to survive and thrive, and organizations hoping or nievely thinking they can rely on a Vendor as a platform to take a short cut to Application governance is now for sure a myth.
Can EA rise to the occasion? Traditional EA and John Zachmans interpretation that architecting the Enterprise through EA does not make the grade in todays world of Rapid change. Business and People are changing and reacting to markets pressures and opportunities. Volatility needs - agility. EA can and must step up to work in tandem with the business and IT function to ensure rapid change and volatility can be accommodated where necessary.
The IT function must embrace and not fight and resist change. IT must become a partner to business and not just hinder business. The Governance Risk and Compliance function must be rest assured that through applying rapid change in certain areas to help business, inherent risk of moving more quickly, is irradicated. Programs and Projects and PMO's also have a key role to play here - they must become conversant with Agile development techniques - again where they count to accommodate this flexibility where necessary. Services Vendors must also play ball. Support Structures must adapt and evolve to enable dynamic and rapid change. In other words its not just the technology stack and the application vendors that are changing - Service Providers, Delivery Practices and Governance Practices must also evolve and advance to keep up.
EA is where this all meets. EA is where the action is. EA is where the burden and opportunity falls. EA is where the answer to this conundrum lies.
At the GT Group we are very much at the forefront of this change - and reporting back on market observations and seeking to lead the charge into this brave new world. What do others think and see and observe? Is the time now ripe to bring EA to the forefront of leading the change and becoming THE enabler for the agile and competitive enterprise vs. a percieved and sometimes in practice an inhibitor?
Join us in this community to advance the thinking and interelationships and role EA plays.

Enterprise Architecture – Effecting Rapid Change and Agility

It is evident today that Information Technology applications and infrastructure, and business models are going through a necessary, massive and rapid change. These changes include:

- Licensing and software access models – Software as a service, (SAAS)
- Services Orientated Architecture (SOA) - considerations and opportunities
- Server and Database Virtualization
- New innovations such as RFID, Collaboration, WEB 2.0, and Mobile
- IT delivery models and support models - Agile, Offshore / Outsource
- The business world being dramatically segmented through globalization
- EA is again being recognized as the business “Meta Model” for a whole organization to help organizations raise to the challenge of the above shifts

Enterprise Architecture (EA) is twenty years old, and just as the technology and processes EA looks to support are changing rapidly, and in order to remain effective in today’s and tomorrows fast and changing world, EA must evolve. Until now EA has been a silo’d function, and has limited capabilities when applied to helping an organization become agile.

Hardly any organization during these past 20 years actually completed an EA as it has been defined in the major frameworks. Because the people engaged in EA are generally technical by nature, most companies focus on the technical piece of an Enterprise Architecture (FEA Technical Reference Model for example) and never really with a Strategic position (i.e. align the IT and operational investments with the Strategy such as the FEA Performance Reference Model). A major problem for EA practitioners is to get the technical people to grasp the Business and ADM (arch. deve. method) layers and most importantly the way to speak and engage and add value to the business.

EA has often begun and ended as an exercise in IT asset inventory and standardization. Who cares if you have standardized assets if they are the wrong assets to support the business strategy? The original goal of EA was to cause this alignment to occur, which does require the ability to affect all the pieces.

However EA has its limitations, so its perception must change quickly to be effective. In order to execute successful EA’s we must focus on business critical segments and use EA, in conjunction with business skills, program skills and technology skills to have high impact and fast effective change.

To achieve and sustain this rapid change, EA Frameworks and Methods are not just key parts, but critical parts. By combining these tools, including Program and Project methods (PMP for example), all touch points within an organization are integrated and aligned, including business, customer, other Programs and Projects, IT, infrastructure and even internal and external Audit functions.

In order for EA to be successful it is necessary to have the right skills that cross not just EA but an advancement of EA i.e. Business, Function, Program and Project Management and ERP. Consider the analogy of building your house and living in it at the same time. This is the challenge for EA.

Enterprise Architecture is not an end state. Enterprise Architecture should be continuously evolving with deliverables represented as a series of rapid transition architectures in the areas that represent the highest value and most volatility to the organization – where architecture agility is critical.

Program and Project Managment - Thoughts

The need for adopting a hybrid project management methodology and approach is to recognize project managements critical role in IT implementations, whilst simultaneously acknowledging that despite a massive and ever growing base of awareness and a long 40 plus year history of IT, many IT projects of all shapes and sizes still end in failure of one form or another.

The solution to this problem is more complex than deriving yet another set of best practices around project management methods, and training them out to an increasingly aware set of practitioners. This is helpful, an essential first step, but is not enough.

The program and project management community must also be empowered with new and broader knowledge, skills and capabilities, and equipped with Enterprise class tools and methods that when combined can enable them to become more effective and add real value in today’s increasingly fast paced world of continuous change.

A five year ERP program delivered in a traditional Waterfall or Plan Driven approach stuggles to come to terms with the rapid changing world. How can a program or project predict a set of requirements that forecast 5 years out – when IT Technology and business iteself is changing in cycles more akin to months than years?

How on the other hand can a seemingly chaotic free for all software implementation methodology like Agile designed to address this particular shortcoming of a Plan driven approach be applied to rigid Enterprise Class / Enterprise Wide COTS (Commercial Off the Shelf) Enterprise Software implementations?

The answer to this apparent dichotomy is to fuse a series of world class Enterprise class best practices and methods to form a new and superior approach that fosters communication and collaboration on a continuous and ongoing basis between all stakeholders involved with, impacted by, or responsible for an IT implementation.

This community involved or impacted by Enterprise IT implementations has become so large now, and the business is moving so fast and the technology changing so fast there is simply no choice but to adopt such an approach. Thoughts?

OK – So you say we need EA - what is it exactly? – Part 1

We have talked a lot about the importance of EA relating it to a health program – and this makes sense, and inferred that many organizations will at some point touch on EA. Now let’s explore how and why.

If there is one verb in the English language that summarized the function or act of Enterprise Architecture it would be “Integrate”.

Enterprise Architecture gives the verb “to Integrate” a scope and context for IT, but if you understand why you a) would want to integrate anything in IT and b) the challenges with integrating anything in IT you are very close to understanding the single most important aspect and purpose of EA.

In this vain “we are building an enterprise architecture” can also be “we are integrating IT”, or “We have an Enterprise Architecture” can be said as “We have an integrated IT”.

Now this point alone raises some interesting questions, like for instance if this is true, how many organizations can honestly say they have “ an enterprise architecture” as in end-state? They will certainly have the verb “practicing EA” but I would challenge the noun “have EA” as this implies something is finished that by definition never is or can never be as never is everything integrated!

Let’s continue to further explore this notion of integration then.

Picture this... If I were standing addressing a room full of C level executives and hardcore technical folks from software engineers to infrastructure specialists and say yourself......and I were to ask the whole room two simple questions ...

1) Stand up everyone who thinks they are right now challenged one way or another by a lack of systems integration. How would you answer? And if you were in the room what would you see?

2) Sit down everybody who does not see integration is a problem right now....again what do you think you would see?

And then finally if I were to offer all those standing the opportunity to socialize on the theme of integration... Would they not have something to talk about?

EA then is about.... “Integration”. This is why it’s current, critical and important and ultimately inevitable. In fact in this context all of us – whether C Suite executives, Users, or technical specialists, are already dealing with EA everyday – we may not know it, we may not be actively embracing it, we may be fighting with it – but for certain at some level we are touching on it.

EA is the way to tame the integration beast in the same way projects are a process way to get initiatives done.

Did you catch the nuance in the exercise relating to the real importance of how EA actually does contribute? I will start Part 2 with this.