http://iasaglobal.org/making-architecture-and-brms-successful/
Mostrando entradas con la etiqueta IASA. Mostrar todas las entradas
Mostrando entradas con la etiqueta IASA. Mostrar todas las entradas
miércoles, 20 de mayo de 2015
lunes, 23 de febrero de 2015
miércoles, 11 de febrero de 2015
lunes, 2 de febrero de 2015
miércoles, 21 de enero de 2015
jueves, 18 de diciembre de 2014
martes, 16 de diciembre de 2014
martes, 25 de noviembre de 2014
domingo, 19 de octubre de 2014
martes, 14 de octubre de 2014
lunes, 1 de septiembre de 2014
miércoles, 28 de mayo de 2014
martes, 27 de mayo de 2014
jueves, 1 de mayo de 2014
viernes, 25 de abril de 2014
lunes, 14 de abril de 2014
TOGAF is not Enterprise Architecture
http://www.iasaglobal.org/iasa/NewsBot.asp?MODE=VIEW&ID=74
Let me start by saying TOGAF is a fine framework and if it is what your organization has selected that is great. This post is less about TOGAF and more about EA and making it work...
What is it about architects that makes us want to describe everything in a framework and then treat that framework AS everything? Oh common we all do it. EA's, SA's, IA's, all of us are guilty of trying to framework-atize whatever we are working on. It is probably one of our best features, and it is probably one of our worst.
Recently I was talking to a chief architect about architect education. One of the things that we discussed is that the organization has standardized on TOGAF and that nothing else would be allowed. I clarified that architecture education isn't about a framework it is about skills and capability development regardless of framework. Survey after survey both internal to their organization and within IASA shows that architects do not feel that they are prepared or have all of the skills necessary to do their jobs. Yet time and time again people think that TOGAF or UML or MSF or Struts or the Unified Process or whatever are architecture.
Lets put this clearly a SKILL is the ability to complete a job that is acquired over time. Sometimes a skill uses tools. Say for example you would like to be a good presenter. Some of the TOOLS you have to choose from are Keynote, PowerPoint and Open Office. Or like me you may often present without slides (I often find it is easier to capture an audience if they aren't constantly staring at a screen).
A framework is another tool (and not a very clear one at that since it is used equally for Zachman Views, TOGAF which is a methodology and portal components which is a technology framework). A framework is not the skill or the point of the activity in the first place. For example, the ADM from is basically a methodology like UP, MSF or SCRUM. It is a process for doing things. In this case it is a process for doing architectural things instead of developmental things but just a process none the less. There are other methodologies out ther for architects. FEAF, DODAF, MODAF, and others include methodology components. And your organization may choose to mix and match these or not use them all together. But what is the point, the goal and the skill?
The point is to use a common process to make architecture easier and better, the goal to save time and hence save money and the skill.... Applying Architecture Methodologies. Wow that was complicated. Learning TOGAF may help you with one company but what if you go to work for the DOD (Dept of Defense)? They use DODAF and well um you will be out of luck. Learn the skill not the tool and everything will stop 'looking like a nail'.
Oh by the way, methodologies like TOGAF aren't even comprehensive from a process perspective. Governance, Strategy Rationalization, ROI calculation, Technology Framework Selection, and the other 75 things listed in the architect skills taxonomy we've identified have NOTHING to do with it.
- See more at: http://www.iasaglobal.org/iasa/NewsBot.asp?MODE=VIEW&ID=74#sthash.hLhUlla6.dpuf
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? 
sábado, 1 de marzo de 2014
Suscribirse a:
Entradas (Atom)