Frameworx

How to assess the value of employing Frameworx and Enterprise Architecture

Adrian Grigoriu — Sun, 25 Apr 2010 09:55:08 GMT

With the advent of EA, the whole Enterprise should be better understood, its operation streamlined, the strategy effectively mapped, duplications reduced, projects aligned in a portfolio with dependencies cleared, and prioritization improved... Frameworx, representing in fact a reference integrated business architecture would constitute the backbone of an EA solution. The method discussed here may be used to evaluate the value of applying Frameworx to your business.

I once classified the principal advantages of the EA in four categories: Operational (improved operations, technology resources aligned to business needs), Strategic (vision mapped and implemented), Governance (better governance structures, decision making...) and Communications and Collaboration between people (having same EA vocabulary...).

Of course, there is a difference between EA and the framework used i.e. Frameworx. Nonetheless, the framework enables the construction of the EA with all the benefits at a fraction of the cost, since it is saving you the effort of developing the right framework which effort, if unsuccessful, will inhibit any further EA development as it is so often the case. Imagine you have to re-invent the architecture and principles of a car design each time you build one.

Benefits in each category can be classified in a table of key benefits indicators that can be used to justify and guess/estimate the value of the EA development. The benefits have to be expressed as relative values to the no-architecture case, in percentages.

While the EA is delivered, the table can be also used to measure the actual value of each indicator and as such, in the end, an overall relative figure for benefits. One can change/add to the key indicators, as well. Thus this is a method rather than a prescriptive procedure.

Overall, assuming the simplification that the key indicators equally contribute to benefits, the relative revenue/costs ratio of the architecture versus the non architecture case will give you the return in terms of relative revenue over relative costs that can be rounded to give anyone a more clear picture of what to expect from the development. The better the framework and EA the better the return which also increases with the EA deployment progress.

Because the business thinks in financial terms, considering the EA and Frameworx a competitive asset, an NPV can be calculated, taking into account the initial development costs over a period of time plus the relative revenue vs costs of the architecture vs non architecture case, calculated as stated before.

Why do you need this? Because you need to justify the costs of building an EA based on Frameworx - in other words you need to build a business case - and then quantify progress in delivering the business benefits not only the EA.

This is all described at length in my book available at Amazon, Trafford and elsewhere. Reviews are available from BPTrends and Angry Architect.

So long, Adrian

Leadership and again SOA reading

Adrian Grigoriu — Sun, 18 Apr 2010 12:22:57 GMT

"There is an argument that the Enterprise Architect is a leader in the transformation of the Enterprise and a participant in the business decision making process. Right now, this is not the case but the trend points in that direction.

But what is a leader or leadership for that matter? And what is it compared to management? Management is about organization, control, planning and budgeting. Leadership is about motivation, mobilization, creating the vision and establishing the culture and relationships. To succeed, an Enterprise Architect has to act as a leader to motivate people, mobilize resources and create the EA vision while as a manager has to manage the complexity of the Enterprise Architecture development, documentation and day to day running." (quote from my EA book).

Now, what HBR has discovered is suprising:
"We’ve found that contrary to what many CEOs assume, leadership is not really about delegating tasks and monitoring results; it is about imbuing the entire workforce with a sense of responsibility for the business. This applies mainly to knowledge organizations, but even production-oriented companies can benefit from having employees who feel more empowered and engaged." Read this.

"In chaotic times, an executive’s instinct may be to strive for greater efficiency by tightening control. But the truth is that relinquishing authority and giving employees considerable autonomy can boost innovation and success at knowledge firms, even during crises. Our research provides hard evidence that leaders who give in to the urge to clamp down can end up doing their companies a serious disservice.Although business thinkers have long proposed that companies can engage workers and stimulate innovation by abdicating control—establishing non-hierarchical teams that focus on various issues and allowing those teams to make most of the company’s decisions—guidance on implementing such a policy is lacking. So is evidence of its consequences. Indeed, companies that actually practice abdication of control are rare. Two of them, however, compellingly demonstrate that if it’s implemented properly, this counter-intuitive idea can dramatically improve results."

Now about architecture SOA and EA. More reading fortunately - or not. For SOA and the Cloud integration read comments on my ebizq blog here.
For those who want to understand the whole EA process in a 3 minutes or so watch this.

So long Adrian

SOA is not dead says IDC and other SOA stories

Adrian Grigoriu — Mon, 12 Apr 2010 16:33:02 GMT

Ruediger Spies, vice-president of enterprise applications at IDC Central Europe, at IDC’s "SOA and Beyond" Conference 2010 said that business spending on SOA will grow by up to 25 percent worldwide by 2013. Good news for SOE. Here is the post. Spies said that SOA, if designed properly, will provide the basis for BPM strategies, which he described as a "pretty small step" from cloud computing.

He also emphasized that "although integration is one of the key challenges of cloud computing, if you've done your SOA properly, you will have the roadmap for the process architecture and the information architecture that builds the groundwork of things, and how they should fit together."

Still “typically, SOA projects have a longer life span than ERP systems, which last around 12 to 13 years..." (Spies says). This is a bit surprising: do we thing that much ahead? Do we calculate the returns for that long amount of time? That may explain why SOA is thought dead.

SOA vendors embark on "Cloudwashing" — “renaming technology, strategies, and services to using the term ‘cloud." says David Linthicum. And Anne Thomas Manes of Burton Group (which should be Gartner nowadays) adds that "using cloud computing without a sound architectural context is dangerous. Organizations that blithely run off and deploy applications in the cloud without considering SOA principles will find themselves in worse shape than before."

And that "just because it's dead, that doesn't mean we don't need it" (Anne). SOA died a hero's death: "SOA is dead, long live Services" another motto coming from the Anne's thinking. There is a particular brand of technological wisdom contained, that I have to think twice about, that is, if it makes sense.

Oracle has a whole series on SOA amongst which a paper on SOA best practices.

In the end, I just wanted to reinforce the value of SOA and business services. But SOA is so much more than a technology. We need to engage the experts for each business domain of the Enterprise to be able to define services functionality and interfaces. That means a complex program composed of a wide project portfolio. And SOA needs an architecture upfront to make sure that same service functionality is not duplicated time and again.

Approaching it from a technology alone line of sight is a mistake. As it often happens, we say this is the technology, the rules... this is SOA. We first need to design the services and prove that they implement properly the enterprise business flows and transactions. Technology integration comes last.

So long, Adrian

http://it.toolbox.com/blogs/ea-matters/

Communications and OMG's Architecture Ecosystem

Adrian Grigoriu — Thu, 01 Apr 2010 14:11:14 GMT

This is a light posting in preparation for the Easter break. As an aside to the architecture posts, I would like to share with you this link about communications. In spite of everything, isn’t the industry we work in "communications"? We never do enough about communication at own peril. How do we get it right?

When, at some point in my career, I used to work in speech intonation synthesis and recognition, it was said that tone counts more than words; like "Yes, right", meaning in fact the opposite, depending on intonation. Compare

What do we have for dinner mum?
to
What do we have for dinner, mum?

A pause associated with the comma, changes the meaning. This was a classical example in the field of intonation recognition, underlining the importance of other speech clues in addition to sounds and words recognition.

When communicating in writing we lose this important message recognition component, the intonation, even though we compensate with punctuation. We also lose it when listening to a synthesised mechanical voice of a Call Center. We lose the information communicated by the human emotion.

Also our spoken discourse may be negated not only by our tone but by our gestures or the expression of our face, like an inappropriate smile in a grave situation.

Communication means transmission of information between two sides. The message has to match the language and conventions of the receiving side as well.

After all, we are an International multi-cultural community where native gestures and intonations are so different. We have to know then when to discard or learn intonation and body language clues because they are in another "language". Pay also attention to false friends, that is, same words in different languages have different meanings.

Well, communication is easier said than done. Think about presentations and performance anxiety.

Back to business, there is news from OMG on the formation of "the Architecture Ecosystem Special Interest Group (AE SIG) to provide for improved definition and integration of models and modeling languages within an ecosystem where modeling tools and languages can be used together more effectively. While direct participation in the AE SIG is limited to OMG members, non-members are invited to monitor the group's activities through an open email list. For more information, visit the Architecture Ecosystem Wiki: http://www.omgwiki.org/architecture-ecosystem". Great, would that be UML?

Adrian

SOA , Enterprise Architecture, Frameworx and a word of caution

Adrian Grigoriu — Wed, 24 Mar 2010 10:59:01 GMT

This is to draw caution. Service Orientation and Enterprise Architecture are without a doubt, the way. And Frameworx includes elements of both. But a careless execution could spell failure.

SOA, in a W3C definition, means "a set of components which can be invoked and whose interface definitions can be published and discovered." A dram too simple to my liking.

From an IT point of view, SOA is an integration technology for application services. A service is an application component which exposes an interface (hiding the internal implementation technology), published in a registry and eventually, dynamically discovered.
Web Services have been implementing the SOA paradigm over Web protocols. As a result, SOA is often associated to Web Services and its technologies (SOAP, XML, UDDI, WSDL...).

From a business angle, SOA is a style of business architecture design and, ultimately, a way of structuring your business. It enables a Business Oriented Architecture by allowing the business to define Enterprise workflows around reusable business services. The services and their interfaces have to be designed by the business cognizant, rather than the application developer. - At this point I would interrupt my tirade to say that this is a most special part in defining Enterprise level Frameworx business services.-

SOA imposes a new business process design, implemented as an orchestration of loosely coupled SOA services. It is an evolution of BPM aiming to encapsulate and hide complexity in business services. In SOA, the business workflows will consist of orchestrated SOA services that encapsulate process, information and the technology implementing it.

What is the relationship between SOA and Enterprise Architecture (EA)?
A “Service Oriented Enterprise Architecture,” SOEA, defined as an EA with an SO style of target architecture, would better describe the positioning of SOA with regard to EA.
The EA sets in place a method to achieve technology and organization alignment to business processes, strategy, and objectives.
SOA does cover architecture, but it does not specifically address business process automation, IT alignment to strategy..., even if it helps; it does not document the As-Is state like EA does; and it does not provide guidance for the development program as EA frameworks do.
SOA, as a style of business architecture, is adding value to the EA by enabling modularity at the business service level, and, as such, agility, reuse, Quality of Service, facilitating payback mechanisms and service contracts.
EA may be implemented without SOA at the cost of flexibility and agility. A stand-alone SOA development, solely driven by a service orientation architectural requirement, would fail to achieve the business needs and goals and would lack method.

SOA requires a large Enterprise process re-engineering and re-design effort, with significant consequences, at process, applications, infrastructure, and people Enterprise Architecture layers. Services will be reused, access will be enforced through SLA contracts, and a new SOA services governance will be in play, affecting the existing organization. SOA, given its scope and ambition, should be a joint business and IT effort, a key part of a full EA development, and not considered in isolation as a light IT Enterprise Integration effort.

If you need to know more here is the whole SOA whitepaper.

Adrian

Beyerstein's pseudo-science criteria

Adrian Grigoriu — Fri, 19 Mar 2010 14:32:53 GMT

What are the characteristics of pseudo-science? Here is Beyerstein's list of characteristics of pseudoscience as exposed in Patrick’s Lambe’s post on “Is KM a pseudoscience?“:

Isolation – failure to connect with prior and parallel disciplines
Non-falsifiability – no means to invalidate hypotheses
Misuse of data – leveraging data out of context or beyond validity
No self-correction, evolution of thought – often centred round a single ‘thought-leader’
Special-pleading – the claim that this is a special-case that can’t be measured in any other terms
Unfounded optimism – unrealistic expectations
Impenetrability – an over-dependence on complicated ideology and obfuscation, or bluster in place of debate
Magical-thinking – such as “the belief that good things will result from willpower alone”
Ulterior motives – particularly ulterior motives of a commercial kind
Lack of formal training – including certification schemes that link back to #4
Bunker mentality – such as complaints about being ‘misunderstood’ by others, and often linked to #5 and #7
Lack of replicability of results – especially replicability by others under controlled conditions

It sounds familiar though. I would dare apply the criteria to technology not only scientific work. Does this apply to what we do, frameworks, standards, best practices? Surely not.
Is this valid for what you do? I'll leave you think about it.The list is thought provoking and worth checking.

Adrian

Frameworx, Enterprise Architecture and the science of complex systems

Adrian Grigoriu — Fri, 12 Mar 2010 14:13:02 GMT

"...Our natural inclination is to reduce matter first to molecules and then to atoms... But this approach...does not always work. In other words, the whole can often be more than the sum of the parts. Just consider the beautiful patterns created by large flocks of birds flying in the sky, which cannot be explained by understanding in ever greater detail the physiology of those birds. It is the interactions between the birds that are the key: the patterns form if each individual simply keeps a steady gap between it and its neighbours and flies in their average direction... This is the science of complex systems -- a rapidly growing field that tackles any system with lots of individual elements that interact in some way, be they birds flying in formation, car drivers moving along a highway or computers linking to form the Internet." Read more here about the science of complex systems.

An Enterprise is a complex system of people and technology. It is created by humans, typically and unfortunately, without a blueprint. We wish its parts fly in formation, like the ducks, to the same destination, but do they? We need to understand the alignment mechanism of the flight. But how do the birds do it, after all? For one, they follow a V formation, more often than not, that is a kind of flight architecture.

But how do we make the Enterprise fly? We should be able to do it better than the ducks, for sure. We may adopt the V formation or we may not.

Maybe the Enterprise Architecture approach would help us understand the flying formation of our organization, of our processes and systems that form the big picture of our firm and enable us comprehend what keeps them working together
But what is an Enterprise? It is a group of people organized to deliver a product, using technology.

What is Enterprise Architecture? It's the Enterprise structure and its operation blueprint. Simply architecture in our own words. EA documents stakeholders' use cases as business flows and the technology and organizational resources executing them.

An Enterprise has many problems today: the silo organization, the point solutions duplicating functionality, the unnecessary complexity and the poor understanding of the Enterprise operation causing poor implementations, a lengthening of the decision making, and a failure to deliver in time the business change. That renders the Enterprise unresponsive in a world of growing complexity and change.

The Solution is indeed Enterprise Architecture meant to streamline your Enterprise, enable faster product delivery at lower costs, handle the exploding amount of complexity and information and provide greater agility to cope with change.

What is our approach? Frameworx, a reference Enterprise Integrated Business Architecture.

Yours, Adrian

Transforming your Enterprise and Frameworx

Adrian Grigoriu — Fri, 05 Mar 2010 19:32:10 GMT

I choose to chat again about Enterprise Architecture and EA frameworks.

"If you have ever watched a house being built, or if you have ever had an addition put onto an existing house, you know that the standard method of communication is a big piece of paper called a blueprint. Blueprinting is the standard method used to copy large architectural and construction drawings. A blueprint used to consist of white lines on a blue background. A more recent process uses blue lines on a white background." (from here).

The blueprint is designed by the architect and used by the plumber, electrician, owner, potential buyer... It comes with guidance documentation, when necessary. A plan of transformation is the result of strategy executed as (a portfolio of) projects transforming the blueprint components.

The blueprint reflects the structure that changes in time with its purpose. The architecture could be classic or baroque, depending on the architectural style. The relationship between structure and its purpose is shaped by the architectural style.

Similarly, the EA blueprint is not static. It should be constantly updated to reflect the change in structure result of all on-going projects in an Enterprise. That may not always happen but this is the role of the EA architect.
The EA blueprint is the base of all conversations on changing the structure to fit the purpose or fitness for purpose, maintenance, renovation and transformation. It should be the basis of change in the Enterprise, be it operational, tactical or strategical. Without a blueprint, the transformation cannot be properly managed; the Enterprise would grow organically until a point when nothing works properly any longer and its decay starts.

The EA, as a blueprint, should be seen as the cornerstone of any Enterprise transformation, as a strategy, as in the title of a well known but less practical EA book.

But the core of any EA development is the framework, i.e. its meta-architecture. And Frameworx represents a reference EA meta-architecture populating the 4-layered EA model with true Business Process, Information and Application reference architectures. It may be used either stand alone or along TOGAF ADM (Architecture Development Method) for instance.
What is your view? I'd invite you to debate here.
Adrian

Gartner's Opening Keynote 2009: SOA Health Check - In Tough Times Reconsider, Evolve and Enable Change

Adrian Grigoriu — Thu, 25 Feb 2010 18:18:51 GMT

"Despite SOA adoption being the highest in Europe (nearly 70% of European organizations), few companies master the art of building SOA, and the more difficult art of using it to a company's advantage. In times when it is absolutely vital to prove the value of every initiative, this session will introduce the content of the conference and start unveiling how SOA can contain costs, get more out of your existing assets, exploit discontinuities in the market, and simply ride a disruptive innovation wave."
Prepare for growth again is one of the messages. Listen here.

Gartner SOA & Application Development and Integration Summit 2010
14 - 15 June, London, UK
http://www.gartner.com/it/page.jsp?id=1128412

Adrian

Business Process Practices and Business Architecture reading

Adrian Grigoriu — Thu, 18 Feb 2010 18:30:04 GMT

How do we employ our Business Process Framework, eTOM, to align, improve, implement... our processes?

Here are a couple of interesting articles from BPTrends that may help us, about processes, re-use and why not practices and culture.

Also, for the architect a reference to SOA Consortium's business architecture.

“What happens when well-designed processes do not align with the practices of the supervisors who perform them?... Even with well designed processes, the behavioural practices of groups and individuals can make the difference between merely adequate results and outstanding results.”

Practices and ultimately culture influence the outcome of a process.Follow this link.

Process re-use is not as easy as it seems. Try to redeploy the same process in the retail, corporate or on-line space. It does not work. What we re-use is the pattern.
“We can employ reuse in many ways. Employing best practice is one form of reuse (we are reusing concepts and ideas); process standardization is another (we are reusing the whole process); reusing process components or business services is yet another. A good process is one that does not reinvent everything from scratch, but reuses many process and IT components.”
eTOM is listed in the article as a process framework. Read here.

And the Business Architecture from SOA Consortium. Don’t hold your breath though.

So long

Adrian