Tag Archives: architect

Challenges of Emergent Architecture

By Balasubramanian Somasundram, Honeywell Technology Solutions Ltd.

In 2009, Gartner had coined a term called ‘Emergent Architecture’ advocating the need for a re-orientation in Enterprise Architecture practice. According to this paradigm, Gartner suggests Enterprise Architects must adopt a new style of Enterprise Architecture to respond to a growing variety and complexity in markets, economics, nations, networks and companies. Gartner had also listed some of the characteristics of such an Emergent Architecture and the kind of changes that we can foresee in near future.

After two years, I wanted to take a closer look at this observation and correlate some of my personal experiences from Enterprise IT.

To set the context, would like to quote the emergence of situational applications. In simple terms, situational applications solve immediate business challenges by addressing a situation in hand. The key characteristics of situational applications are – unique situation, highly personalized, immediate and time-sensitive nature of business scenario.  A “situational application” is a broader term that includes concrete implementations such as Mashups and Composite applications.

So far, Enterprise IT has been busy with ERP/CRM and packaged applications and custom developed web applications. Now, that era of “hand coding” is almost saturated and hit a plateau due to couple of reasons such as – Enterprise roll-outs of ERP/CRM are complete, custom developed applications are rationalized and consolidated with ERP suites and demands for new custom developed applications are challenged for solid business cases.

However, the unique business situations still demand for small/nimble IT solutions that wouldn’t wait for long lead times, big business cases. What is the solution?

Situational Applications can help.

The key characteristic of these situational applications is that business doesn’t have the details about the requirements or responses. All it has is the outcome that needs to be achieved. Sometimes, business just wants to experiment with multiple options before zeroing on one solution. In some cases, business wants to build just a pilot, scaled-down version of the actual solution and eventually evolve it to an enterprise-class solution. Sound familiar?

I would say this is one of the categories of emergence scenarios that Enterprise Architecture needs to deal with, for both business and IT stakeholders.

In contrast to what Gartner states, the key challenges that EA needs help solving are not just macro issues such as geopolitical risks or outsourcing governance etc., but micro issues that would help executing day-to-day projects much more effectively. This will build the credibility of EA groups at grassroots level and drive some real changes in business/IT. I would like to list some of those challenges to be solved:

  1. Given the uncertainty in requirements and technologies, what is the best way to cater to these business requests for building situational applications? Certainly, agile methods can help to certain extent. But the scenarios that revolve around situational applications are much more dynamic and need much faster results. Another way to look at this challenge is, how do these unique business situations fit in the overall business architecture?
  2. How do we engage business users to gather requirements in creative ways, especially when business users themselves may not have all the data upfront?
  3. If we need to build nimble, simple IT solutions, we need to have a solid architecture foundation. How can EA help both segments? – foundational and situational
  4. How do we make sure we create an ecosystem where the new architecture ‘evolves” as the requirements and solutions themselves evolve over a period of time?  How do we make sure architecture not only evolves, but translatable to an enterprise-scale solution?

Thanks to The Open Group, we have robust frameworks and methodologies for building deterministic enterprise architectures. It will be interesting to see how The Open Group addresses the demands and challenges of nondeterministic/emergent enterprise architectures as stated above, in the future.

Enterprise Architecture is a subject that will be discussed in depth during The Open Group Conference, London, May 9-13. Join us for best practices and case studies on Enterprise Architecture, Cloud, Security and more, presented by preeminent thought leaders in the industry.

Balasubramanian Somasundaram is an Enterprise Architect with Honeywell Technology Solutions Ltd, Bangalore, a division of Honeywell Inc, USA. Bala has been with Honeywell Technology Solutions for the past five years and contributed in several technology roles. His current responsibilities include Architecture/Technology Planning and Governance, Solution Architecture Definition for business-critical programs, and Technical oversight/Review for programs delivered from Honeywell IT India center. With more than 12 years of experience in the IT services industry, Bala has worked with variety of technologies with a focus on IT architecture practice.  His current interests include Enterprise Architecture, Cloud Computing and Mobile Applications. He periodically writes about emerging technology trends that impact the Enterprise IT space on his blog. Bala holds a Master of Science in Computer Science from MKU University, India.


Filed under Enterprise Architecture

Is Enterprise Architecture a Profession?

By Jason Uppal, QRS

I have been involved with the Enterprise Architecture (EA) industry for the past 12 years. If the number of open positions for Enterprise Architects is any indication, there are a great many vacancies for EA opportunities that are going unfulfilled. Every time we discuss how to close this supply and demand gap for architects, the same question arises time and time again – is Enterprise Architecture a profession or discipline? Having some insight to this question – if not a complete answer – will help us further define the curriculum, mentoring and process to develop architects.

The purpose of this blog is to discuss what makes a profession and how to apply this to Enterprise Architecture. The July-August 2010 Harvard Business Review explored a similar subject – Is management a profession or discipline? I would like to apply the same thinking to Enterprise Architecture and would welcome your comments.

What makes a Profession?

The HBR article outlined the following characteristics of a profession:

  • Professions are made up of particular categories of people from whom we seek advice and services because they have knowledge and skills that we do not.
  • We cannot judge the quality of information ourselves even after the actions according to the advice and/or service has been implemented.
  • Since a professional is an expert and we are not, there is always an asymmetry of knowledge.

Scenario for Medicine as a Profession

Let’s apply these characteristics to a well-known profession such as a physician. After a four-year hiatus from marathon running, I asked my family doctor for advice on how to approach my training, the goal being that I just wanted to complete the marathon in less than four hours. He reviewed my physical condition, training plan and demeanour from past records and provided me with a training plan, nutrition plan and regular checkup schedule. During the training, he helped me understand how best to use the tools he provided. The final result, I completed the run in 3 hours and 45 minutes, without injuring myself, and still had enough strength to celebrate afterwards.

Situation Diagnostics – Could another physician have given me a different plan that would achieve the same results? The answer is perhaps yes, but as an information seeker I would have never known. I needed to trust my physician as the expert and that I did not have the expertise to judge the quality of his advice. This information asymmetry will permanently exist.

Scenario for an Enterprise Architecture as a Profession

Let’s apply similar scenario to an Enterprise Architect. Three years ago, I was asked by a manufacturing VP (George) to help upgrade his company’s aging manufacturing production infrastructure with a financially viable business case. For simplicity, let’s ignore other constraints for now. I studied the current situation, defined the target state, quantified the business benefit of being at the target state, validated it with key stakeholders, defined the transition map, created the architecture  — including total cost, benefits, risk and impact of the change on people. We presented the architecture and business case to the CEO in three slides and in seven minutes. He looked at both of us and said, “Are you telling me that you can solve the production problems at that price” – which was half of the anticipated price – “and deliver these benefits by this schedule?” The answer came, “Yes sir”. He immediately said, “George, we should do this program.”

Situation Diagnostics: I framed the problem, defined, implemented and exploited the capabilities to deliver the results at a certain cost and risk appetite. Would George – given his own abilities – be able to determine that the problem could have been solved for half the costs and less risk and impact to the organization? The answer is no, unless he asks another architect for a second review of the problem. This option is not very realistic in practice.

In conclusion, I would like to say that Enterprise Architecture is a profession where we define the role of Enterprise Architect as a person who takes responsibility for the definition and development of necessary Enterprise Capabilities required to achieve the goals and provide expertise based in leading the exploitation of those capabilities until the intended outcome is achieved. This is no different from what I asked my physician in the scenario above.

Are we ready to define and accept Enterprise Architect’s role as above? I welcome all feedback … negative and positive.

This post was originally posted to the QRS blog on April 16.

The profession of Enterprise Architecture is a subject that will be discussed in depth during The Open Group Conference, London, May 9-13, both in public sessions and during The Open Group Architecture Forum meetings. Join us in London for best practices and case studies on Enterprise Architecture, Cloud, Security and more, presented by preeminent thought leaders in the industry.

Jason Uppal, P.Eng. is the Chief Architect at QRS and was the first Master IT Architect certified by The Open Group, by direct review, in October 2005. He holds an undergraduate degree in Mechanical Engineering, graduate degree in Economics and a post graduate diploma in Computer Science. Jason’s commitment to Enterprise Architecture Life Cycle (EALC) has led him to focus on training (TOGAF®), education (UOIT) and mentoring services to his clients as well as being the responsible individual for both Architecture and Portfolio & Project Management for a number of major projects. Jason has found that education is only beneficial to those companies who can industrialize the EALC process – staff must be able to implement what they have learned. To that end, he lead a team of java software developers to develop an end to end industrialization product which encapsulates Enterprise Architecture, Portfolio and Project Management, Project Management and  IT Services Management processes. Implementing this software product, ITO, (www.itoProcesses.com.) permits companies to take full advantage of TOGAF® and any other custom processes which might already be in place within their organization.

1 Comment

Filed under Enterprise Architecture

Believe in change

By Garry Doherty, The Open Group

Many years ago I remember watching a TV documentary about the Apollo 11 moonshot. It was, as you would expect, very interesting; however, the only real memory of the program which has stayed with me was of a segment of the program which had little to do with Apollo 11 itself.

The cameraman was recording some footage of a guy who was cleaning the floor with a mop. An interviewer entered shot and engaged the cleaner… the dialogue went something like this:

Interviewer: Hi there, I wonder if you could give us a few minutes of your time?

Employee: Yeh, sure.

Interviewer: It must be amazing to be part of a team like this?

Employee: I guess.

Interviewer: Do you ever get the chance to meet any of the astronauts?

Employee: Oh no, sir.

Interviewer: So, what is your main role here?

Employee: I am helping to put a man on the moon.

Today, I am still humbled by that admission. Here was a man, who, despite his lowly manual labor, knew exactly that he was part of a team and understood his organization’s goals and the nature of his contribution.

So what can Enterprise Architects learn from this?

Well, at least part of what Architects do is to initiate change; but initiation is only the beginning. It’s not just enough to explain what change is going to happen; it’s also critical to explain why the change is necessary and what the impact that change will bring.

So, bear in mind that it’s not enough to just tell people. They need to believe as well!

Garry DohertyGarry Doherty is an experienced product marketer and product manager with a background in the IT and telecommunications industries. Garry is the TOGAF® Product Manager and theArchiMate® Forum Director at The Open Group. Garry is based in the U.K.

Comments Off on Believe in change

Filed under Enterprise Architecture

New year, new certification

By Steve Philp, The Open Group

At the beginning of every new calendar year, many organizations discuss with employees specific job-related objectives and career development plans for the next 12 months and beyond. For many individuals, certification is highlighted as something that they should be working towards during the course of the year.

Until recently, virtually all IT certifications have been based on an individual’s recollection of a body of knowledge and his/her ability to pass a computer-based test. Unfortunately, these certifications do not prove that you can apply this knowledge successfully in practice. To achieve certified status you usually have to attend the relevant training course or read the appropriate self-study material before taking the examination. However, knowledge in itself is not an accurate measure of competence and, while question-based tests are practical and objective, they are also more susceptible to fraud.http://www.freedigitalphotos.net/images/view_photog.php?photogid=1152

Perhaps a better method of evaluating competence to carry out a specific role is to examine the skills and experience that an individual has demonstrated in his/her work. This type of certification usually requires you to prepare some form of written application followed by either an individual or panel interview which may or may not involve a formal presentation as part of the process.

In recent years, The Open Group has developed the IT Architect Certification (ITAC) and IT Specialist (ITSC) programs that are based entirely on skills and experience, and that assess an individual’s “people skills” as well as their technical abilities. There is no test-based examination but instead, applicants must complete a comprehensive application package and then be interviewed by three existing certified board members. Each of the interviews last for one hour and gives the candidate the opportunity to explain to the interviewer how they have met the conformance requirements of the program.

Many organizations around the world have identified this type of skills- and experienced-based program as a necessary part of the process to develop their own internal IT profession. These certifications can also be used in the recruitment process and help to guarantee a consistent and quality-assured service on project proposals, procurements and on service level agreements. As a result, the benefit of achieving this type of IT certification often proves to be much more rewarding for both individuals and organizations.

Steve PhilpSteve Philp is the Marketing Director for the IT Architect and IT Specialist certification programs at The Open Group. Over the past 20 years, Steve has worked predominantly in sales, marketing and general management roles within the IT training industry. Based in Reading, UK, he joined The Open Group in 2008 to promote and develop the organization’s skills and experience-based IT certifications.


Filed under Certifications, Enterprise Architecture

The Newest from SOA: The SOA Ontology Technical Standard

By Heather Kreger, IBM

The Open Group just announced the availability of The Open Group SOA Ontology Technical Standard.

Ontology?? Sounds very ‘semantic Web,’ doesn’t it? Just smacks of reasoning engines. What on earth do architects using SOA want with reasoning engines?

Actually, Ontologies are misunderstood — an Ontology is simply the definition of a set of concepts and the relationships between them for a particular domain — in this case, the domain is SOA.

They don’t HAVE to be used for reasoning… or semantic Web. And they are more than a simple glossary which defines terms, because they also define relationships between them — something important for SOA, we thought. It’s also important to note that they are more formal than Reference Models, usually by providing representations in OWL (just in case you want to use popular tools for Ontology and reasoners).

What would an architect do with THIS ontology?Image credit: jscreationzs

It can be used simply to read and understand the key concepts of SOA, and more importantly, a set of definitions and UNDERSTANDING of key concepts that you can agree to use with others in your company and between organizations. Making sure you are ‘speaking the same language’ is essential for any architect to be able to communicate effectively with IT, business, and marketing professionals within the enterprise as well as with vendors and suppliers outside the enterprise. This common language can help ensure that you can ask the right questions and interpret the answers you get unambiguously.

It can be used as a basis for the models for the SOA solution as well. In fact, this is happening in the SOA repository standard under development in OASIS, S-RAMP, where they have used the SOA Ontology as the foundational business model for registry/repository integration.

The Ontology can also be augmented with additional related domain-specific ontologies; for example, on Governance or Business Process Management… or even in a vertical industry like retail where ARTS is developing service models. In fact, we, the SOA Ontology project, tried to define the minimum, absolutely core concepts needed for SOA and allow other domain experts to define additional details for Policy, Process, Service Contract, etc.

This Ontology was developed to be consistent with existing and developing SOA standards including OMG’s SOA/ML and BPMN and those in The Open Group SOA Workgroup: SOA Governance Framework, OSIMM, and the SOA Reference Architecture. It seems it would have been good to have developed this standard before now, but the good news is that it is grounded in extensive real-world experience developing, deploying and communicating about SOA solutions over the past five years. The Ontology reflects the lessons learned about what terms NOT to use to avoid confusion, and how to best distinguish among some common and often overused concepts like service composition, process, service contracts, and policy and their roles in SOA.

Have a look at the new SOA Ontology and see if it can help you in your communications for SOA. It’s available to you free at this link: http://www.opengroup.org/bookstore/catalog/c104.htm

Additional Links:

Heather KregerHeather Kreger is IBM’s lead architect for Smarter Planet, Policy, and SOA Standards in the IBM Software Group, with 15 years of standards experience. She has led the development of standards for Cloud, SOA, Web services, Management and Java in numerous standards organizations, including W3C, OASIS, DMTF, and Open Group. Heather is currently co-chair for The Open Group’s SOA Work Group and liaison for the Open Group SOA and Cloud Work Groups to ISO/IEC JTC1 SC7 SOA SG and INCITS DAPS38 (US TAG to ISO/IEC JTC 1 SC38). Heather is also the author of numerous articles and specifications, as well as the book Java and JMX, Building Manageable Systems, and most recently was co-editor of Navigating the SOA Open Standards Landscape Around Architecture.


Filed under Cloud/SOA