The Open Group Conference Boston 2010

The Open Group convened Enterprise Architects the world over in what is probably the conference capital of the world – Boston, from 19 – 23 July 2010. Here are a few statements from the speakers on Day 3 – on the significance of IT people in general, the EA practice, the growing list of skills required of Enterprise Architects, and a little on cloud computing.

“IT people are the best people to address the relevance of IT within companies” – Jack Calhoun, CEO, Accelare, US

“Decisions cannot be made in a vacuum without having the proper data and the context for that information. Enterprise architecture can help businesses pose the correct questions and provide the necessary data to make better decision making scenarios.” – Paul Johnson, CEO, Pragmatica Innovations

The following statement shows that business does involve some level of emotion – the ability to inspire through a well-described vision in addition to providing hard data can weigh the vote in your favor.

“Because getting buy-in becomes more difficult the further up the decision-chain one goes, Mr. Skilton suggested that a combination of providing vision, quantitative analysis and qualitative information is necessary to begin the conversation.” – Capgemini’s Mark Skilton, Global Director, Applications Outsourcing

We better come up with a better title for the Enterprise Architect – Superhero?

Psychology, sociology and communications though are some disciplines I did want to get a degree for back in college. Maybe one day… Interesting how all my interests have come together under EA. Maybe that’s one of the reasons why I find EA so intriguing. It’s multi-faceted and not limited to “IT”. It reaches beyond the cold boundaries of technology or corporate games. I guess it’s because behind all that technology are flesh-and-blood, living and breathing and feeling humans. In a way, I chose to go into IT to numb myself from the world and lose myself in bits and bytes and code but there’s no escaping the human drama.

“As a discipline, EA has evolved as a practitioner-based discipline that grew out of the need to have IT professionals that could have an overarching view of the enterprise. EA is also a way for the enterprise to take a holistic view of every level of the organization. Because EAs need to have a holistic view, they also need to be capable of systems thinking. With the focus of IT shifting to the business, EAs now need a set of skills that can encompass many disciplines including an amalgam of systems engineering, IT trends and processes, and organizational theory related fields such as psychology, public administration, communications and sociology.” – Beryl Bellman, Academic Director, FEAC Institute

The following statement made me LOL – probably the most adjectives in one statement ever. Funny but true. Just imagine the amount of pointless meetings you’ve had to sit in and you have the first adjective defined – garrulous.

“Most effective organizations are “garrulous, clumsy, superstitious, hypocritical, monstrous, octopoid, wandering and grouchy.” – Beryl Bellman, Academic Director, FEAC Institute

“Forrester does not believe that Cloud is the “next big thing” in IT—rather, the next big thing is smart computing—which includes smart networks, data centers, mobile devices, and smart applications—of which the cloud is actually just an enabler of these things.” – Forrester Research analyst Henry Peyret


Posted by rochelleolviga


While You Were Sleeping…

Granted, your company’s batch processing may be running smoothly while you sleep. Or the interruptions may be at an acceptable level not to keep you up at night. But there may be some situations that warrant a review of your batch processing – like a company merger where the systems of the amalgamating companies have to ‘talk to each other’ OR like a major purchase of a COTS that has to be integrated with your existing legacy batch process. In either case, fusing two batch processes can have a compounding effect on the Batch Window which may adversely affect your Batch SLA.

3 Improvement Areas

In one of the companies I was employed at, I found and worked on resolving 3 issues that achieved significant improvement to the batch window. Looking at these 3 areas may also assist you in your batch tuning efforts.

1. Obsolete jobs that are still running

2. Incorrect job dependencies resulting in job streams (JS) running later than they should thus affecting downstream jobs (see sketch below)

3. File transfer job parameters are incorrect resulting in slow file transfer times and delay in subsequent jobs

My Sketch of a Simple Job Dependency Scenario

The Big, Black Box of Batch

Solving these 3 issues sounds simple enough. The challenge is, when you start to put a magnifying glass to the big, black box called ‘batch’, it is like opening Pandora’s box – you usually have thousands of jobs to look at, incomplete or even non-existent documentation and you must be very cautious when implementing the solutions (especially when you do not have sophisticated monitoring tools) as even a small mistake can cause the process to go haywire. This is especially probable of issue # 1 & 2 above. Some of the things to take note of:

After creating a list of batch jobs, you need to identify their logical classifications (e.g. function, frequency, criticality, etc.) but for some jobs, you cannot determine the function or criticality or even necessity and there is no documentation to reference plus the person who can already left the company years ago. If in doubt, it is safer not to alter the job as changing it could have unexpected results.

You do not have a testing environment that closely mirrors the production environment so the changes you made in the testing environment may behave differently in the production environment. Again, caution is key. If you are lucky enough to have sophisticated tools, then you have more confidence putting the changes into effect.


After your batch tuning exercise, it is also important to communicate the actions taken and what Software Engineers or whoever creates and supports the batch jobs, need to do to ensure the inefficiencies do not reoccur. The ideal scenario of course if your resource allocation allows, is to have a batch management team or staff in place to proactively monitor batch performance, at least maintain a repository of information on the different batch jobs and give advice on the best insertion point for a new job. The other way is to conduct regular batch ‘spring cleaning’ exercises.

Your batch support staff will thank you for a good night’s sleep.

To read more about Batch Performance, visit for white papers.

Related Posts:

The Synthesizing Mind – Batch optimization can be an exercise in synthesis and patience! Read this post to be introduced to a book that can encourage you. You are not alone.


Posted by rochelleolviga

Is the Demand for Enterprise Architecture Talent Increasing?

Based on Kelly Services’ annual Salary Guide, the answer seems to be Yes.

There are 2 positions listed in the guide that are related to the Enterprise Architecture (EA) discipline – 1) Solutions Architect and 2) Enterprise & Architect. Below is the salary trend for these 2 titles over the past 4 years.

Solutions Architect – Minimum & Maximum Salary Trend

In what could be attributed to the recession, 2008 shows a decrease in Solutions Architects’ maximum salary. But this picked up the following year, going back to the same level as 2007.

Enterprise & Architect – Minimum & Maximum Salary Trend

Notice that this position appeared in the guide starting 2008 which shows the industry starting to recognize the significance of EA or its principles.

Job Descriptions

So what does the industry expect from a Solutions Architect or a Enterprise & Architect? These are the job descriptions from the guide.

Solutions Architect – Provide pre and post sales support in an IT vendor environment by developing the technical architecture and design of systems or applications. Provide technical leadership and subject matter expertise in various stages of the sales and project delivery lifecycle.

Enterprise & Architect – Design IT systems setup.

Does this mean that most Solutions Architects are consultants instead of in-house staff? In a way, this makes sense as to be a Solutions Architect, you need a broad range of experience made possible by working in a consulting company as opposed to working at the client side where exposure to various technologies is limited and the time to build a portfolio of projects is longer. This is unless the organization you work in is aggressive in its technology plan.

As for the Enterprise & Architect, the description is quite general. In fact, in a survey done by BP among its architects, it was found that the architect’s role was vaguely defined. So BP started a program that includes the TOGAF certification.

The TOGAF Architecture Skills Framework

Following the TOGAF Architecture Skills Framework, there are actually more than a few roles under a typical EA undertaking, namely:
1. IT Designer
2. Program and/or Project Manager
3. Architects – for each of these areas: Enterprise Architecture, Business Architecture, Data Architecture, Application Architecture, Technology Architecture
4. Architecture Manager
5. Architecture Sponsor
6. Architecture Board Members

As EA adoption in Singapore advances, we hope to see the industry-recognized position of Enterprise & Architect more specified and see more positions created under the EA umbrella.

Starting a Career in EA

If you are interested in an EA career, you may want to learn more about EA and how you can build upon your existing skills towards one of the EA positions listed above. Example: If you want to move into an Applications Architect role, these are the skills you need to have at an expert level according to the TOGAF Architecture Skills Framework.

Generic Skills:
– Teamwork
– Inter-personal
– Oral communications
– Written communications
– Logical analysis

Business Skills & Methods:
– Business case
– Business scenario
– Business process
– Business metrics

Enterprise Architecture Skills:
– Business modeling
– Business process design
– Role design
– Organization design
– Application design
– IT industry standards
– Services design
– Architecture principles design
– Architecture views & viewpoints design
– Building block design
– Solutions modeling
– Benefits analysis
– Business interworking
– Systems behavior

IT General Knowledge Skills:
– IT application development methodologies & tools
– Programming languages
– Brokering applications
– Information consumer applications
– Information provider applications
– Web-based services
– Service level agreements
– Enterprise continuums
– Management utilities
– Infrastructure

Technical IT Skills:
– Software engineering
– Security
– Transaction processing
– User interface

Quite a comprehensive list but if you are an IT mid- or higher level manager and especially if you have a Software Engineer background, you should already have most of these skills save for the Enterprise Architecture skills. A good course on EA which includes creating a graded EA paper for a real-world case should give you a good start. Presently, the Institute of Systems Science at the National University of Singapore has such a course.

Reference: TOGAF 9 handbook


Posted by rochelleolviga

A Lesson from BP’s Enterprise Architecture Practice

The latest news in the Enterprise Architecture (EA) world is energy company BP’s adoption of IT Capability Maturity Framework (IT-CMF) to assess its EA management capability. Using the IT-CMF process, the company conducted a survey among its architects to identify weaknesses in its EA framework. To address these weaknesses, BP applied solutions which I think we as mid-level managers can find useful whether our organization has an EA program in place or not.

Lesson: How to Bridge the Strategy – Execution Gap
One of the weak areas found in the survey was the link between the Strategic Planning and Portfolio Management process. Sound familiar? It’s the classic Strategy-Execution gap. So how does BP take a crack at this most quintessential of problems? They do so by mapping applications to business processes which in EA parlance is The Application / Business Process Matrix. My last year’s course notes on EA shows it as a 2-dimensional matrix with ‘Business Processes’ on the Y-axis and ‘Applications’ on the X-axis.

My Sketch of a Simple Application / Business Process Matrix

The usefulness of this matrix is, as an IT manager, you can easily see which applications need to be enhanced owing to a particular strategy based on the business units / processes which that strategy touches on. On the other hand, you can provide justification for an application enhancement by showing the business processes that require it and subsequently the strategy behind it. Ultimately, maintaining your own Application / Business Process Matrix for your area of responsibility can help your organization more effectively execute its strategic plans. You can start with a rough sketch and subsequently build on it as your knowledge and experience grows.

BTW, BP takes it a step further by categorizing applications by criticality.

View the news article.


Posted by rochelleolviga

The Synthesizing Mind

Two significant things attracted me to buy Howard Gardner’s book ‘5 Minds for the Future’ – first, it’s about the future (myself being a bit of a future & trends enthusiast) and two, The Synthesizing Mind (myself being a big-picture thinking enthusiast as well). According to Howard Gardner, there are 5 minds or ways of thinking that we need to master to be able to cope in the future i.e.: 1) Disciplined, 2) Synthesizing, 3) Creating, 4) Respectful, 5) Ethical.

So I am particularly interested in the Synthesizing Mind as looking back, much of the work I had done in the last 5 years was a sort of synthesis – putting different pieces together into meaningful collections i.e., slowly building a diagram of the different systems in operation. Without sophisticated tools, information was tedious to collect, taxing to sift through and equally onerous to prepare into a presentable format. But it was something I found rewarding especially when some of the pieces came together and I could see clumps forming here and there. And it was not simply an academic exercise – the overarching goal was to streamline the architecture and eliminate systemic errors and performance problems. I juggled this with my other role as Project Manager – possibly the polar opposite of the Solution Designer role! I often had to shift from one thinking mode to the other – from the deep thinking ‘Design’ zone to the fire fighting ‘Project Management’ zone and vice versa.

I also recall synthesis being mentioned in the Enterprise Architecture (EA) certification course I completed last year – that ‘Architecting is a synthesis of form and is holistic’ as opposed to ‘Engineering which is an analysis of function and is reductionist.’ In this way, this book or particularly the chapter on The Synthesizing Mind is relevant to EA and coherency enthusiasts.

Howard Gardner is a professor of Cognition and Education at the Harvard Graduate School of Education.


Posted by rochelleolviga

Beginning Enterprise Architecture

I like Enterprise Architecture. But using the word ‘Like’ and ‘Enterprise Architecture’ in the same sentence seems ripe with skepticism given the current environment. Contradictory interpretations of Enterprise Architecture (EA) abound and has left a lot of people confused and indifferent to it. Several are doubtful of the future of EA adoption. Add this to the existing communication problem between the business and IT departments i.e., tech-speak. Like it or not, the onus lies heavily on IT professionals to go the extra mile to present technical information in a way that is relevant to the business. More so as outsourcing becomes the norm.

The Changing Role of IT Professionals

Those of us who survive the ‘selection process’ are expected to be less technical and more business-like, acting as correlators and translators of business strategies to technical design and vice versa. This is a significant albeit painful shift in perspective in an already change-driven environment. As for EA, in itself it is not a purely technical endeavor but it seems that it is in IT where the beginning waves are formed.

People Don’t Buy What They Don’t Understand

Realistically speaking, people only begin to like what they understand. As an occasional entrepreneur selling my pre-loved stuff on the Internet (e.g. eBay, Craiglist and other sites), I have learned this to be true. Examples: I know the value of having a photo vs. not having one in my ad listing – a good photo draws more views. I also know the value of a good product description – it helps to differentiate my ‘product’ and people may or may not buy but they leave a comment and respond to your email. I also know the value of timing my ad posts – I noticed that posting an ad around the weekend draws the least views. And I also know the value of targeting my stuff to a particular group as well as pricing appropriately – people are more responsive that way.

Doing these things have made me a few sales – yes, few but at least I do not go away frustrated by a lack of response the way I did when I first started out. They take more time but they promote better understanding which leads to interest which leads to a purchase and possibly a future- or cross-sell. Giving confusing information leads to page abandonment or no click-thru at all.

As it is for commodities, so it is for EA. Understanding begets liking OR not liking and the latter is better than utter indifference.

The Business Case for EA

The tragedy of EA appears to be the apathy surrounding it, especially on the part of business. Or is EA simply in the stage which Geoffrey Moore calls The Chasm? I.e., the dark adoption divide between technology enthusiasts and the mainstream majority. Or the adoption gap between visionaries and pragmatists. Until those who hold the purse strings are convinced and find enough financially rewarding reasons to start an EA program, it will be Business As Usual.

Can We Practice EA without an EA Program?

Without a corporate-sponsored EA program, can those of us who believe in the promise of EA practice EA? I believe we can still apply the principles of EA but on a smaller scale. In fact, this approach could be advantageous. Geoffrey Moore (Crossing the Chasm) proposes finding a niche, focusing on it and later on using its success as a reference point to convince the pragmatic (Early Majority) and conservative (Late Majority) adopters. To draw another parallel with my experience hawking second-hand stuff on the Internet, I usually put a ‘SOLD’ sign next to my ad listing after I’ve sold the item – it conveys validity and somehow trustworthiness which hopefully makes other viewers more comfortable to buy from me.

In this blog, I will be posting examples of how to use EA methods, small-scale. Watch the ‘EA in Practice’ category.


Posted by rochelleolviga

About This Blog

If you (tick all that apply):

– like technology

– like observing trends

– like thinking about the future

– like big-picture thinking

– like integrating systems

– like game changers

– are an IT mid-level manager* wanting to change the world with IT, one implementation at a time

then you are like me and this blog is for you!

Working in the complex and fast-paced world of technology doesn’t mean IT professionals always want ideas in Greek or in Geek-speak. IT professionals also want simple, practical ways to cope in their day-to-day tasks and contribute in meaningful ways to their organization.

So, here is my credo, the ‘IT Sketchbook Manifesto’, if you will.

The IT Sketchbook Manifesto

I believe in The Napkin Test – concepts can be made simple enough and bite-sized enough to be adopted and used. If you can sketch it on a small piece of paper, people are more likely to understand it and use it, yourself including.

I believe in The Snowball Effect – large, enterprise-wide implementations can be daunting. Convincing a group of people of a new concept can be near impossible as well. It makes sense to start small and build on the momentum.

I believe in The Big Picture – call it a holistic view, or a higher level of abstraction, looking at the Big Picture has benefits not limited to corporate organizational effectiveness. Your personal health, the environment and society as a whole also stand to gain when you work on widening your perspective and expanding your view.

* IT Mid-level Manager – Someone whose one foot is on the ground and the other around senior IT management i.e., you need to translate or correlate strategy to technical design / technical approach and vice versa.


Posted by rochelleolviga