By: Jan Stafford
When building dependability into systems and software, the buck often stops at the enterprise architect. While the architect plays a key role, ensuring dependability is a team effort, and business executives can and often should be project leaders, said Chris Forde, The Open Group’s general manager, Asia Pacific, and vice president of Enterprise Architecture.
By submitting your personal information, you agree that TechTarget and its partners may contact you regarding relevant content, products and special offers.
Forde offers advice on achieving system dependability and career opportunities in embedded software development in this Q&A. Before joining The Open Group, Forde was an enterprise architect for several organizations, most recently as vice president for Strategy and Architecture for their Customer Servicing Capability for American Express. The Open Group is a vendor- and technology-neutral advisory, standards-creation and certification organization, which recently released the Dependability through Assuredness (O-DA) framework. For Open Group, Forde played a key role in the development and launch of TOGAF 9.
What are some indications that a system is not dependable, other than just shut downs?
Forde: The frequency of degradation in service levels observable by the customer (internal or external) from nominal, not failures. This is often cited as more frustrating than total outages, it may also go unreported.
Considering that there is no 100% dependable system, what are the practices that will lead to a low failure rate?
Forde: One is the actual prevention of the failure by recognizing the issue in its early stages as it is developing and taking corrective action in advance; that is, being able to measure prevented failure. A simple example is in effective management of storage or network capacity. Fundamentally, capacity planning and timely provisioning of certain infrastructure components [reduce failures]. Often, this is not done well.
How does constant change impact dependability?
Forde: Change introduces the risk of error, complexity and interoperability compound that risk. O-DA is a mechanism to address mitigating that risk.
What kind of challenges does a mix of cloud, embedded, web and mobile pose for an enterprise architect?
Forde: To a certain extent, architecture implies the effective use of known standards/component or in some cases developing and setting those standards within an enterprise. As these technologies emerge and evolve, they cross into the ‘extended enterprise space’ and reflect the exponential proliferation of endpoints and platforms and information. A lack of standards around emerging technologies is in itself a headache for architects. Attempting to construct fit for purpose solutions with a reasonable lifespan to in order recoup investment, and allow a migration path as things change is a common issue concerning architects.
In the embedded systems area, what career opportunities do you see for enterprise architects today?
Forde: The fact that there are embedded systems is related to expertise, if these systems have a position in an enterprise relative to other systems then they are in scope for an architect’s role. For [the Asia Pacific] region, the software development parks in Shanghai have embedded systems context charts on the walls, and these educational and development sites are also engaging in discussions about the need for EA’s training. They wouldn’t be doing both of these things if there were not an opportunity in the marketplace for jobs.