6 years, 11 months ago

Challenges of Project Management on an EA-Driven Solution : A Blog Series

by Allan Borra, MSCS

Sitting as Project Manager AND Enterprise Architect

In a series of blogs, I’m sharing my experiences, challenges and eureka moments related to my dual role as a project manager and an architect to a solution development project driven by Enterprise Architecture.  I’ve managed  software solutions development projects before and have varying levels of applying project management disciplines and I’m usually using the software development lifecycle (SDLC) method. So it was a fun and learning experience for me to alter my usual “success” recipe by using Enterprise Architecture (EA) discipline in the mix. This methodology is similar to what is called Solution Architecture as defined by Gartner1.
It is observable that locally there are varying degree of awareness, compliance and maturity of Enterprise  Architecture work in organizations. I happen to be working for a pioneering and leading  EA consulting company who engaged a solutions development project for a government agency. The government agency has no enterprise architecture or capability  in place and the agency management has no (with some misconceptions even) to little  knowledge about Enterprise Architecture.

IT groups in government agencies, especially the one we are currently engaged in, are very comfortable with  traditional SDLC methodology. It fits nicely with the current government procurement law2. Nevertheless, we had a unique opportunity here to really push for an Enterprise Architecture-driven software development to complement the SDLC methodology (or any software development methodology for that matter), due to the fact that the terms of reference (TOR) explicitly calls out Business/Data/Application/Technology (BDAT) architecture requirements and standard notations such as Archimate.
Challenge 1: Changing Mindsets
Herein lies the first challenge: managing client expectations on project activities and deliverables. I’ve heard of an anecdote that goes “Change Management is easiest without people”. It was a really a concern  for me back then that the client wanted the solution as  soon as possible and that, even as the TOR calls out deliverables on BDAT architectures, these are not “primary” requirements for them. The client is accustomed to the SDLC or traditional methodologies that allow for only a certain level of business and functional requirements elicitation that is just enough for the software design and  implementation.  This meant that a semblance of the software solution could be out in a month or even as soon as  codes  are translated  from the functional requirements.

Figure 1. TOGAF Architecture Development Cycle
Enterprise Architecture, using The Open Group Architecture Framework Architecture Development Methodology (TOGAF ADM)3, entails going through different phases as shown in Figure 1. Critical to the requirements of the Terms of Reference for the project are Phases B, C and D. The method allowed us to view all their process documentations, if available, or elicit and model processes that are undocumented. These process models and artefacts take part in the Business Architecture. We then looked into their data both from a high or conceptual level and from a low or physical level. It took great lengths of mapping these conceptual data models to the business processes, moreso getting the complete business processes, interactions and information flows  documented themselves. Then we looked into their existing applications, modelled and related it to the processes to which these applications serve. We looked at their current infrastructure as well and modelled a target architecture by which the infrastructure can fulfill the requirements of the applications that services the processes that fulfills the intended performance of the solution that complies with the TOR. Needless to say, we considered legacy, third-party data and applications, out of scope processes in the mix of the overall  architecture. Ultimately, all of these need time without outputting a single line of code yet. Three months spent on EA work without a line of code yet for only a year-long project. For sure the client  was very impatient.
It was a painstaking “selling an idea, selling yourself” stint for me as I ventured in winning over the client and have them be on our side for this methodology: EA-driven solution development. What partly worked was communicating the value proposition of doing the EA work. For sure,  there’s tons of references out there that list these: 1. Alignment of technology to business strategies; 2. Aids in achieving business strategies; 3. Managing complexity of the enterprise; 4. Faster design and development of solutions; etc.. At the start of every meeting, I give a few minutes to orient key client stakeholders on the EA framework and the value this provide. The orientations ran for more than a month until we had some considerable artefacts and architectures to show for.  This worked in a way that when there are differences of expectations, it’s always a heavy, difficult conversation with clients, while, if there’s a level of agreement on expectations, conversations are smooth and affable. And we are having these kinds of conversations, already. But I did mention that communication only partly worked, because at the end of the day, there’s still no solution or line of code to show. I just can’t take all of that away from them, for now.

And then, eureka! The architecture surfaced the complexity!  When one can visually breakdown a complex network of interacting components and dimensions of the organization, or in this case, the solution and its  interactions with the organization, managing all of that becomes simple.  In my next blog, I’ll discuss how EA + tool shows the complexity and how it aids the communication: bringing the client to our side. I’ll share as well,  how visualizing the complexity helped me as PM  with decision-making based on these architecture artefacts.

1Gartner IT Glossary: Solution Architecture. Accessed June 2017. Retrieved from

2Government Procurement Policy Board. Republic Act 9184: Government Procurement Reform Act. 2002. Retrieved from http://www.gppb.gov.ph/laws/laws/RA_9184.pdf

3TOGAF® 9.1 Part II: Architecture Development Method (ADM). Introduction to the ADM. 2011. Retrieved from http://pubs.opengroup.org/architecture/togaf9-doc/arch/chap05.html

Talk to Us.

© Sinag Solutions

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

Ortigas Center, Pasig City, Philippines, 1605

Office: (632) 956 5175

6 years, 11 months ago

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

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)


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

6 years, 11 months ago

SOA Enable Technology Neutral

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

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

6 years, 11 months ago

EA = Enterprise Agility

Enterprise Architecture equals Enterprise Agility
by Mike “MO” Oliver, SOACA
Arhicecture word cloud.png

So how does Enterprise Architecture translate into equaling Enterprise Agility, other than the acronyms both being EA?


One key element of any quality Enterprise Architecture is the setting and governing standards across the enterprise.  If you have standards on how to do this or that, then you will likely have templates for various code elements or perhaps you have standardized on a Framework or Enterprise Service Bus.  All of these will reduce the training time, design time, and development and testing time to build a solution or service.  Saving time in going from concept to production is by definition improving agility.

Service Oriented Architecture (SOA)

Enterprises that adopt SOA for their strategic integration approach do so largely because of the efficiency  and productivity gains a Service Oriented Architecture can bring. SOA and the Microservices subset are all about designing solutions around small service components that follow separation of concerns and loose coupling paradigms, which also translate into better agility through more granular design and reusable services.  If 50% of the services your current solutions use are reusable, then building a new solution will take much less effort and time, giving you better agility.

Business Architecture

Following TOGAF and documenting your Business Architecture may not seem like it helps translate into Agility, but look at it this way.  If you do not have your Business Architecture documented fully, then as problems and opportunities arise (and they will), how do you know for sure that you don’t already have something in place to do the job? Or worse how do you know what the gap analysis is from what you have to what you need?  That takes time and if you make a mistake and miss something, then you may spend even more time and money to get it right later.  This all translates into Agility.


Agility essentially comes from two things:

  1. Knowledge that keeps you from making mistakes that lead to wasted time and effort.  Enterprise Architecture is mostly about organizing what you have so you know what you have and what you need, and that knowledge makes your enterprise more agile.

  2. The basic Engineering Principle, DRY for Don’t Repeat Yourself.  SOA, as part of your Enterprise Architecture, puts a priority on reuse, separation of concerns and loose coupling. Do those things and you will avoid duplication of effort which equals agility.

© Sinag Solutions

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

Office: (632) 956 5175

7 years, 22 days ago

A Whole New World

I can show you the world.. Shining, shimmering, splendid.Well I think, everyone has the ability to show the world to someone just like Aladdin, well except for now that it might not that be that shiny and shimmery and real splendid. They say beaut…

7 years, 1 month ago

So, It’s Not That Easy

When EA was first introduced to me, I got my head-bulb lightened. Like ‘ting’. This might be the one I was really looking for. Excitement flourished in my head without entertaining a question at the corner of my mind. What is this?On my previous p…

7 years, 1 month ago

All Because of Change

When the usual chaos of working as an adult, hits you, then it is understandable that you, yes you- will find something else to dry your thirst of new things and adventures.And that what’s happened.I was hired as a System Analyst for Sinag Solutions la…