#eavoices

The Present and Future of the ArchiMate® Language – Part 1

by

Welcome to the first in a series of blog posts on The Present and Future of the ArchiMate® Language. With the release of the ArchiMate 3.0 Specification last year, we now have a complete enterprise description language that has been adopted by architects worldwide in a wide range of organizations. It is now time for the ArchiMate Forum to reach out to users and better understand how the language is being used and how it should evolve. Therefore, the following post, like all others in this series, reflects the views of its authors, and will benefit from comments and discussion. You may refine, expand upon, or even disagree with elements of the post. Regardless, you will be shaping the future of the ArchiMate language.

So please, enjoy and engage!

Architecture Views & Layers of Abstraction and Details: How much is too much?

by
by Francis Uy, TOGAF 9, PMP


As an Enterprise architect, I find myself doing presentations to various levels of the company I am working with.  These presentations aim to recommend actions in order to support the company’s goals.  

My job is to make sure that decision makers are empowered with the right information to make the best choice at any given time. The most effective way for this information to elicit a speedy but quality-based decision is to recommend with the perspective of the person making the decision.  

In the book “3 Laws of Performance” by Steve Zaffron and Dave Logan they state that how people perform correlates to how the situation occurs to them.  This is very true also in how people make choices.  If you can understand how a particular situation occurs to your stakeholder and present information from that point of view, you are likely to get a better response from them.

For example, let’s say I am talking to a project management office (PMO) head.  It will be an easy conversation if I fully understand what his needs and concerns are. From a PMO’s point of view – his metrics are successful delivery of all the projects in his scope.  His concerns are that he has just in time visibility of project issues and risks so that he can support his project managers as soon as possible.  He would also want a tracking of the benefits each of the projects are promising and a visibility on when these will be met.

At his level, the layer of abstraction he needs will be primarily focused on the project views, the program views, or even perhaps the portfolio views. He would not need to see further details as what a project manager would see such as the work breakdown structure — unless one item there is now causing the delay of the benefit being delivered by a project.

Example below shows 2 levels of abstraction for the same set of projects.  The image on the left is a set of projects with their detailed steps.  The image on the right focuses on a summary of the total project health (status, costs, resources, etc)


On the other end of the spectrum, talking to a chief executive officer (CEO) of the company and understanding his concerns vis-a-vis the projects of the company will also ensure being able to successfully support him.  While, similar to the PMO, he does care about the benefits of all the projects in the company, he realistically only has bandwidth for the top 10-30% of them.  Hence ensuring that a filter is provided focusing on that will support his decision making.  Unlike the PMO though, his concerns are looking broader across the whole organization and even extends outside – specially if the company is listed on the stock market.  A key concern for the CEO is change management.  And inside change management a question of – will the projects or initiatives drive the right behavior we need in order to be a more competitive company. He will need views that show a holistic landscape of how all the projects are impacting various parts of his company.  Are we doing too many changes in one particular capability thereby decreasing the returns potential of a particular project?  Are we doing enough on the other important parts of the business?

Clearly, showing the CEO views beyond the whole company perspective — things like detailed design strategies or software details that software engineers and process owners use is definitely too much details.

The example below shows a view that the CEO would care about.  It is the business capability model for his company which shows the key capabilities (parents of business processes) needed to ensure business operations excellence.  Comparing this to the earlier views, a useful perspective is to see how many projects are in flight to improve the cost, risks, or business value of below capabilities. (see numbers overlaid on the capability)


Conclusion:

To be an effective architect, you need to know the key concerns of various levels and functions of the organization.  Presenting your data from their perspective will allow for an easier connection, collaboration, and decision making.

My challenge:  Next time you need to present or influence a key stakeholder stop first and think from their perspective and understand how is the issue or the situation occurring to them.



Talk to Us.

© Sinag Solutions

Unit 903, Antel Global Corporate Center, Julia Vargas Ave, 

Ortigas Center, Pasig City, Philippines, 1605

Office: (632) 956 5175







How organizations model their acquisition and divestiture – a real life example

by

In my previous blog I wrote about the importance of models to successfully complete a merger, acquisition or divestiture. Of course, one organization’s divestiture may be another one’s acquisition. In this blog post I’ll share one my personal experiences as a consultant, supporting two government agencies that were in the middle of this process.

The first 100 days

by

First of all throw away all those books about everything architecture, secondly delete all those special modeling tools, third forget any architecture courses, and finaly say no to architecture consultants. If you followed my advise so far then the next step is to tourist your business and all the things it depends on. Be sure […]

SOA Enable Technology Neutral

by
by Mike “MO” Oliver, SOACA
Service Oriented Architecture (SOA) is often the chosen Enterprise Technology Architecture for
Integration. 

It can bring agility in choosing implementation technologies.

Another SOA Guiding Principle  

Photo from Web
SOA can be realized through a variety of technologies and standards. Just like you cannot buy SOA through a product or technology, or use an Enterprise Service Bus (ESB) and get SOA, you can have a SOA using many different technologies.

SOA can be realized through a variety of products and standards, like ESBs from IBM, Mule or JBoss, or even technologies like Enterprise Application Integration middleware or even Spring Integration.  You can balance it between two vendors, and all of them included in your SOA design and implementation.  SOA is really technology neutral.

One of my clients has Integration Bus, another has Mule, another has JBoss, one has all three with each performing a task that is well suited to that technology.  You can use HTTP for transport, or JMS for transport, or MQ for transport or a mix.  Service Oriented Solutions can therefore be built using just about any technologies and standards that are suitable for distributed computing.


Here are some examples:
One of my clients uses Spring Integration for their SOA Implementation.  The key is that they use a Standardized Service Contract and Canonical Schema design patterns to achieve their SOA without an ESB. The Spring Integration services were therefore reusable and composable.

Another client used Message Broker and they did the same thing, they standardized on MQ Transport and SOAP messages with a canonical payload schema. The used Websphere Service Registry and Repository for the Official Endpoint pattern.

Another used a combination of IBM Integration Bus ESB and JBoss Fuse and JBoss Data Virtualization with a JMS Transport.

So to reiterate, you can use a variety of products, technologies and standards to implement your SOA Design.



Talk to Us.

© Sinag Solutions

Unit 903, Antel Global Corporate Center, Julia Vargas Ave, 
Ortigas Center, Pasig City, Philippines, 1605

Office: (632) 956 5175

Operating Models Must Evolve To Address RPA Gaps

by

The search for “quick solutions” to fragmented business applications has pushed RPA investment. I’ve taken over 200 hundred inquiries on RPA in the last six months and also attended Blue Prism, Automation Anywhere, NICE, and other vendors conferences and spoken to thier customers. About half the enterprises I have talked with are just starting out either in vendor review or staging early POCs, with the other half in production and looking for the next process to robotize. I’d estimate only about 10% are in any form of large scaled opertations. And most have tackled simple processes that I define as less then 200 human clicks replaced by a Bot that access less then three applicaitons.

But things are moving quickly. RPA tools are relatively cheap. And they work fast. There is no requirements document. You can download free RPA software and develop a Bot in a few days. And who needs a business case when projects can be self-funded from productivity gains? Yet, I’m sensing that early enthusiasm has led to tapping the breaks. Here’s why?

Stakeholders are not properly aligned to the emerging digital workforce. Yes. It might take only a month to build the digital worker. But six times that to get management and other stakeholders on board. In most organizations, the number of people working for a person is a measure of importance. So when you tell them you will replace humans with digital workers they are threatened. Tech management also has a long list of objections and may resist small changes to legacy systems that make Bots work better. Senior technical leadership is often not on board. And thats just for starters.

Some bad processes are getting robotized. RPA plugs gaps in legacy systems and sometimes will delay needed system modernization. Some processes you don’t want to institutionalize by adding robots. If we can improve things first, then do it.

Read more

Architecture Corner: Fame on Social Media – Seven Deadly Sins of IT

by

Episode 3 of this season of Architecture Corner is out (I made a guest appearance in episode 1, “Good at Innovation”). In this installment, Chris the CEO is having trouble with a new sin. What happens when the CEO envies the social media presence of his competitors and decides to buy some followers?

Documentation Trivializes Everything

by

Several years ago my colleague Dan wrote about how we Should Not Get Distracted by the Document. Dan made the case that architecture documents are tools to figure out architecture, not the ex-post-facto results of architecture design you’ve already done in less disciplined ways (verbal debates, email chains, “brainstorming” and other adhoc, document-less activities). But I am going to one-up Dan right […]