http://respect-architects.blogspot.se/2015/09/looks-like-we-need-it-architect-right.html
Mostrando entradas con la etiqueta Skills. Mostrar todas las entradas
Mostrando entradas con la etiqueta Skills. Mostrar todas las entradas
sábado, 19 de diciembre de 2015
martes, 28 de octubre de 2014
lunes, 14 de abril de 2014
TOGAF, IASA and architecture skills
http://weblog.tetradian.com/2008/07/02/togaf-iasa/
This one’s a follow-up to a comment by Stanly Johnson yesterday to my “TOGAF Certified” post of almost a year ago:
I feel the IASA skill set and TOGAF (and other) frameworks are essential.
IASA skill set do prepare an individual to become an architect.
Frameworks tells us how to architect a system
The important point here is, you need to learn the skill sets and you also need to understand some matured frameworks and then design (or redesign) your enterprise architecture.
Can you design a system without having the basic skill sets (like IASA), by only mastering an architecture framework (like TOGAF)? Yes, but then you are lucky. Lucky that the methods, tools and patterns specified suited your organization.
Can you design a system only by learning the basic skillsets and not even looking into matured frameworks, Hmm yes, then you are a genius. How many organizations HR will know that you are a real genius?
Your comments are highly appreciated.
I’d agree about the value that IASA provide in terms of skill-sets for IT-architects. The problem is that what we’re talking about here is real enterprise architecture – whole of enterprise architecture – of which IT ‘enterprise architecture’ is merely one small subset. And there are no standard frameworks or skill-sets for that as yet – in fact what we’re doing right now is creating them, for the next generation of architects.
Unlike The Open Group, IASA did recognise right from the start that real enterprise-architecture is a great deal broader than just IT. But at present – and wisely, in my opinion – they’ve concentrated on the IT end, because that’s where the immediate need is.
One aspect of my comment about ‘TOGAF Certified’ was really about exactly the point that Stanly made: how would HR departments know that I know what I’m talking about? The need for some kind of proof of competence goes right back to the days of the masonic handshake – a literally tactile proof that you’d been trained to a level where your cathedral wouldn’t come down on people like, well, many tons of bricks… And although, for what I do, the TOGAF certification doesn’t mean all that much (given that it covers only a tiny subset of the scope I need to address in my work), it’s about the nearest to a generic architecture certification that I can get. IASA certification sounds like a good idea, but in practice it leads me further away from where I need to be – it’s specific, specialised to IT, whereas my emphasis is on whole-of-enterprise integration.
To give a specific example, look at the difference between data architecture and information architecture:
- Data architecture deals mainly with logical models and logical-to-physical transforms. In Zachman terms, it sits happily and comfortably within those two levels (‘logical’ and ‘physical’) of a single segment (‘virtual’) of a single column (‘What’). Plenty of custom-built toolsets exist for this purpose – ERWin, for example, or the data-modelling components of System Architect. It’s (relatively!) simple and straightforward; and though it requires real skill, it’s relatively easy to learn via training – and hence appropriate for straightforward certification of competence.
- Information-architecture deals mainly with business-oriented information – particularly counts-of, averages-of, trends-0f, comparisons-of and other complex derivations and aggregates. Although it seems to end up as ‘virtual-What’, it does not sit there – in fact it often pinballs around the entire Zachman frame, through business-rules (‘Why’), transform-functions (‘How’), skills and heuristics (‘Who’), trigger-events (‘When’) and much more besides, at every level from real-time operations upwards. Trying to model this in a data-architecture tool such as ERWin is a bad joke (says he from bitter experience…); and despite the claims of the vendors, there are no EA toolsets that come close to tackling this properly. Almost invariably there will be many hand-overs between IT-based and non-IT-based transforms – so a strict IT-centric approach (as inway too much SOA at present…) is going to cause big problems. Doing this work requires a high level of skill, which depends on a great deal more experience than a straightforward training-course; and some at least will be highly context-specific – making certification extremely hard, or dubious at best.
And information-architecture itself is just one subset of real enterprise architecture – which is what I’ve been trying to describe for the past ten years or so. And although, yes, I do use “matured frameworks” where they exist – and yes, I do know how to adapt those to the different contexts we find in different organisations – they don’t cover more than a small portion of the scope we need, and half the time we have to do major surgery to those frameworks to correct for the impact of their mistaken assumptions about the supposed centrality of IT.
(An aside: back in the late ’70s, in the early days of micro-computing, it was generally accepted that the worst qualification for working in the field was computer-science – because graduates came to the problems with mindsets, assumptions and experience which were great for big mainframes and DEC-11s, but entirely wrong for the very different trade-offs with CP/M and Z80s and 6502s. The best qualification was linguistics, followed by arts degrees in general – especially graphic design, which was my background then. We have the same kind of problem here in real enterprise architecture: without careful ‘conversion training’, IT-architecture background and experience can often be more of a hindrance than a help.)
So there are no standards or certifications for that whole-of enterprise level. Real enterprise-architecture – rather than IT-architecture getting grandiose ideas about its own importance – is still way too new for that: and to be blunt, I’m one of the few people who’s actually working tocreate those broader standards, and to show why it’s essential to break free of the IT-centric mindset. Hence when Stanly asks “How many organizations HR will know” that I know what I’m doing with this kind of architecture, the short reply would have to be a sardonic “Tell me about it…” – I struggle to get them even to begin to grasp what I’m talking about at all, let alone get to the level of checking my credentials… Hey ho… 
Stanly correctly emphasises the need for both skill-sets and frameworks – rather than trying to get by with just one or the other – but I’d also add that there’s at least one other key component for which we’re likely to need certification: governance. In an IT-centric context I’d recommend at least a base-level ITIL certification, and probably PRINCE2 and Six-Sigma as well. But at the whole-of-enterprise level? – well, who knows? We ain’t there yet – not by a long way. My guess is that something like a cross-merging of ITIL, TOGAF, PRINCE2 and some of the SOA-governance themes will come out of this work – but it’s probably five years away at least. In the meantime… well, we just have to do the best we can, yes? 
domingo, 21 de abril de 2013
lunes, 8 de abril de 2013
miércoles, 3 de abril de 2013
Absence of EA and Risks
http://www.enterprisearchitects.eu/ea/riskswithoutea
Organisations without an established Enterprise Architecture are often faced with unnecessary risks.
An absence of Enterprise Architecture in most organisations has presented the following risks:
- Inability to rapidly respond to challenges driven by business changes
- Lack of focus on enterprise requirements
- Lack of common direction and synergies
- Incomplete visibility of the current and future target enterprise architecture vision
- Inability to predict impacts of future changes
- Increased gaps and architecture conflicts
- Lack of commonality and consistency due to the absence of standards
- Dilution and dissipation of critical information and knowledge of the deployed solutions
- Rigidity, redundancy and lack of scalability and flexibility in the deployed solutions
- Lack of integration, compatibility and interoperability between applications
- Complex, fragile and costly interfaces between incongruent applications
- Decision-making gridlock
- Piece-meal and ad hoc software development driven by a tactical and reactive approach
To avoid these organisational risks and benefit from the advantages, EA can be used as a strategy to achieve an organisation’s mission, which cannot be left for tomorrow. An Enterprise Architecture framework provides a collection of best practices, standards, tools, processes, and templates to assist in the creation of the Enterprise Architecture. To this effect, as an approach, having EA frameworks first simplifies and guides the process through all areas of EA development as creating an Enterprise Architecture from scratch might be a daunting task.
Changing enterprise architect role enables business, software agility
The enterprise architect role has evolved from being the primary enforcers of technology standards to key enablers of business agility. If a business is behind the software technology curve, it's because the EAs are stuck in old roles.
Today, enterprise architects (EAs) must be the innovators pushing organizations to adopt new technologies, like service-oriented architecture (SOA) and cloud applications that allow business capabilities to change along with customer behaviors and business opportunities, according Forrester analyst Sharyn Leaver. An EA needs the skills to harmonize relations between IT and business.
Martin Owen, CEO of EA products and services vendor Corso, said being able to effectively communicate with both sides is a special skill that can help break down barriers. "Most of the people we deal with have business analysts that understand the business process, but don't necessarily know the IT," he said.
MORE ON EAS
The changing role of enterprise architects
EAs target quick results
EAs address business core models
Owen believes it is important to fold an EA into the business structure, rather than just bring one in. "It is as important as having an accountant or sales staff," he said. "People outsource EAs because they don't really understand it. The most successful organizations put EAs directly into the business."
Social and work behaviors are evolving. With businesses becoming more integrated and IT services being commoditized, EAs need to be responsive to changing business models, according to Group CEO Hugh Evans at Enterprise Architects, an EA professional services firm. "More importantly, people are looking for more integrated and seamless experiences from technology, bringing together personal and business use in an easier to consume fashion," he said.
When to bring in an EA
It's best to bring on an EA early in the SOA adoption process. Leaver explained that bringing in EAs from the start can help ensure everyone is on the same page and goals are met. "High-performance EA programs serve as a connective layer between technology and business that guides planning, decision making, innovation and governance activities," he said.
There are many factors which can trigger the need for an EA. According to Evans, typical triggers include:
- Market landscape change (macro-economic, industry and competition);
- Change, review or optimization of business strategies (products and services model);
- Assessment of ways to reduce complexity and drive a simplification agenda, introduce market differentiation or pull efficiency and effectiveness levers;
- Change in program planning, execution and governance;
- Preparation or response for an internal audit; and
- New business cycle planning.
Microsoft Consulting Services senior strategy consultant Nick Malik said an EA is always needed in a medium-to-large-sized organization, but particularly so when a business goes through change. "The real value the EA brings is in connecting a change to its execution in the organization," he said. "Can it lift the right muscles that address a competitive threat? And if it does so, how does it do it in a hurry?"
Getting the biggest benefit from working with EAs
The biggest challenge in working with an EA lies in being clear about management's goals and the EAs expected deliverables, noted Roger Sessions, chief technology officer of ObjectWatch, an EA consultancy. The chief information officer might have one set of expectations and the EA another, potentially leading to a major mismatch.
Definitions of the role of the EA run the gamut from understanding how the whole enterprise works together to finding the most efficient way to use the IT budget. Sessions believes a good definition of an EA is the disciple of minimizing the complexity in IT systems while making sure they are aligned with business systems.
The most successful organizations put EAs directly into the business.
Martin Owen, CEO of Corso
If the goal is to help address complexity, Sessions recommends using the Simple Iterative Partitions (SIP) framework. He believes SIP is best suited for incorporating clouds into descriptions about IT and business systems. He noted, "The cloud is an important platform. We need to know how to leverage it, which means we need to know more about how the apps are structured and relate to the business processes."
Another challenge lies in getting a handle on the projects in the business. Owen explained, "In the past, an EA would report to an IT manager. Now, organizations are finding the need to do proper business planning and bringing it together with the IT function."
Leaver said there are several deliverables one can expect from good EAs. Capability maps can help identify goals in a language that business stakeholders can understand. The EA might also prescribe the future state using target architectures and create road maps to guide transitions.
It is also useful to have the EA describe changes in the architecture using a consistent language, such as Open Group's ArchiMate, said Owen. Frameworks like TOGAF describe the basics of the enterprise architecture by documenting business processes, whereas ArchiMate describes what the architecture should look like. With TOGAF on its own, one person can describe the infrastructure in one way and it is easier to interpret it differently than with ArchiMate.
"The more complex you get with SOA and the cloud, the more people you have to communicate with," said Owen. "If you can learn the language once, it lowers the barriers to communicating about an infrastructure."
Evans recommends defining a clear mandate with roles, responsibilities and scope. In his experience, the step is frequently overlooked. It is also important to be pragmatic. "The 'enterprise' is large," he said. "Take a concern-based approach to architecture, focus on the specific concerns and do just enough architecture to address the concerns."
A deep sense of trust with the EA should also be cultivated. "The EA is facilitating. He is like a catalyst that encourages, monitors, measures and occasionally governs," said Malik. "He is there to make sure the GM [general manager] is able to express his strategy in a way that shows up in his people."
lunes, 1 de abril de 2013
miércoles, 27 de marzo de 2013
EA Skills ?
- Strategic Management (e.g. Balanced Scorecard)
- Enterprise Governance of IT (e.g. CGEIT, COBIT, VALIT)
- Enterprise Architecture (e.g. EA3, TOGAF)
- IT Service Management (e.g. ITIL, ISO20000)
- Information Security Management (e.g. CISSP, ISO27000)
- Telecom Operations Management (e.g. eTOM, Frameworx)
- Innovation (e.g. TRIZ, Lateral Thinking)
- Project Management (e.g. PMI)
- Family Business Management (e.g. FFI)
lunes, 4 de marzo de 2013
EA Services
hi
http://enterprisearchitects.com/services/offering-catalogue/
Offering catalogue
Enterprise Services
Helping organisations use enterprise architecture to deliver business insights and drive change.
Architect Services
Providing services, information and resources for architects to accelerate career performance.
Strategy & EA projects
Strategic frameworks
Developing EA capability
Recruitment solutions
Corporate Learning
Recruitment & career support
Learning & development
Communities & events
Our clients
miércoles, 30 de enero de 2013
miércoles, 9 de enero de 2013
Suscribirse a:
Entradas (Atom)