You can think of Verification as a sanity check. It can be conducted by anyone with general knowledge of the solution by taking each ADE in turn and asking the well formed questions: does this exist? Should it be here?
Validation on the other hand requires a SME; who might even be from a different discipline like business analysis, who has specific and detailed knowledge of the component.

I think that some of the artefacts can be dropped. I have been of the view for a long time now that catalogues and matrixes became largely, if not completely obsolete with the advent of easy to use architecture tools.

While the data memorialized in these artefacts is undoubtedly important they are in reality simply specialized views. Before modelling the data could only be captured in static artefacts like matrixes and catalogues and so it was, because there was no other option. However, the situation changes when you have the facility to dynamically generate views. The old paper based state memorialization paradigm and its assumptions no longer stand.

Any data pertinent to the architecture should be integrated into the model. Only by taking this approach can we overcome the currency issue innate in all static artefacts and move towards the ideal of a "Digital Twin". I can see in the future that it may not even be necessary to proscribe a set of views and that methodology, for want of a better word, might migrate entirely from the state memorialization paradigm to a routine based craft facilitated by the dynamic generation of views from models more cohesive and comprehensive than any of the current the Digital Twin concepts.

While this is unlikely to happen anytime soon, we should be moving towards this goal and leaving matrixes and catalogues in the past is part of that. Let's not help another generation of architects to internalize / routinize an obsolete paradigm.

I'd say there are two. Firstly while they may be technically excellent most Architects actually have very little idea about how to "do" architecture. It's not surprising really no one has prepared them for the role.

The second even more serious challenge stems from the first. That's legitimacy architecture has no legitimacy. Everyone knows your job better than you. The developers think they don't need architecture, the project manager thinks he's is an architect as do the business analysts and even some product owners not to mention business stakeholders! Everyone wants to be the Architect because it's the best job in IT! It still amazes me how often people who couldn't find the bonnet catch on their car some how think that they are technically competent to design a computer system! The industry suffers from rampant Dunning Kruger effect.

Building legitimacy is actually one of the drivers in the development of PraXtice and is responsible for its sociological content.

That's easy, most organizations don't see architectural practice as an issue. Which is kind of surprising given the frequency with which they complain about their architects. And probably because they don't see an issue they fail to grasp the relationship between architecture, modelling and methodology. So they are stuck at this very basic level that gets reset back to zero every three or four years out of frustration. And there's no corporate memory, so they get a new bunch of architects and repeat the process.

That's easy it's practice. The research shows that how you "do" architecture is more important that what you do. Poor architecture method executed well turns out to be more effective than sophisticated architecture executed poorly!

I would say the key messages would be:

Modelling, by itself will not help you, without method its just a picture drawn a different way. It is the relationships between the different views that are the real value of modelling. They provide the context, communication, enforce rigour and create traceability in much the same way that Relationships in the model are actually more important than the Objects. This is just not obvious to the new modeller.

The model needs to be the centre piece of the architecture practice and must become "the best version of the truth". That is why the "Working in the Model" routine is so important. It can be unpopular because routines regulate the Architects' behaviour. But if nothing changes then nothing changes. They also make it much easier to manage the architecture team.

Overall how you do things, routines turns out to be at least as important as the artefacts you create. Routines and their standardizing effect are the path to legitimacy.

Yeah sure, Pictures are what you produce when you don't use a a standard notation. Typically drawn using Visio or some other free form tool.They're inconsistent, have no guiding meta model and so can't be tested. They are not durable and most importantly can't be read. Without explanation, usually verbal, a picture has no more meaning than interpretive dance!

The research is pretty damning on this one, about half the knowledge from a picture is lost to the audience by the end of the presentation, most of it by the end of the day and a month later you'll have to draw the picture again! This is why you find architects in the same practice drawing the same diagrams over and over again, there's no knowledge transfer so each one draws it again as they understand it. What happens then when a third person comes along and finds both pictures? Pictures are not transferable and not durable.

It also turns out that verbal explanations need to be treated with more than a pinch of salt. The amount of let's call it; semantic slip to be kind, is often significant. This introduces ambiguity leaving audiences with differing understandings. As best I can tell this behaviour has two roots. First and I think most often it's the consequence of the artist not having applied sufficient rigour; which is where a good method can help, and so not really understanding the problem. They either don't know what to do or are just plain lazy. The second is sociological it's an avoidance behaviour where the artist is putting off communicating something because they fear it will not be well received. With no memorialization of the briefing its meaning can be subsequently manipulated to whatever is expedient. I mean, can you imagine your doctor deciding not to tell you your blood test results came back bad because they didn't want to upset you? Really!

On the other hand diagrams are all the things that pictures are not. They are testable, transferable and consistent because they use a standard notation with a competent meta model. You don't have to remember anything, you simply read the diagram which is what makes them durable. A diagram will mean the same thing tomorrow as it did today and it did last year. It will mean the same thing to you as it does to me or someone from outside the practice or even the company. I can send diagrams to none English speaking people overseas and they ALL still mean the same thing. Show me a picture that can do that!

I should also point out that there's a third category here. ArchiMate Pictures. In these the artists are trying to fake a diagram by using ArchiMate symbols. If you are doing this using a tool that doesn't enforce the ArchiMate meta models then it's a wasted effort. In fact it may be worse in that it can trick people into accepting the diagram as valid! Then suddenly one day they go “Oh! Wait a minute that can't be right” and that's because it's not right. Architecture is about driving out ambiguity not introducing it. While ArchiMate pictures might be better than pictures I'm not convinced. Let's be honest if you're not going to use ArchiMate as it was intended then let's not pretend. You need to create ArchiMate Diagrams using a REAL Architecture tool Visio is so 1990's.

A lot of people seem to fail to grasp that the real power of ArchiMate comes from the method that guides its use towards the creation of a single “best version of the truth” model. Diagrams are just views of that model. Pictures, well they're just that, an artist's impression and you can't build using them!

A lot of Architects get caught up in the “jee whiz” of modelling, but they are only thinking about it in the context of one diagram or perhaps one solution and that's a very limiting way of looking at things. There's a few things that new modeller's typically fail to appreciate. One is that Relationships are more important than Objects. Another is that a single let's call it the DOT (Digitial Organizational Twin) model is more important than any particular diagram. Diagrams are just a snap shot of a particular view of an ever evolving and improving model; that is the best version of the truth that we have right now. The other thing is that the relationships between the diagrams of a particular solution are more important in establishing a context than the diagrams individually.

Oh! And we shouldn't forget the impact of a DOT on Segment (Domain) Architectures; with a DOT model every solution contributes to the ”mythical” current state model and provides Domain Architects with an integrated view from which they can develop their Segment Architectures. The DOT is the foundation for integrating the various strata of architecture Operational,Tactical and Strategic. And that's another reason why method is so important. Knowing how one diagram relates to another and how those relationships can be used to align, test and even derive other views turns out to be a really powerful tool.

Excellent question! First I'd say it makes architecture reusable. The diagrams are durable, they'll mean the same thing in six months as they do now. So you can suspend and resume projects without losing a lot of productivity. Because you read diagrams and anyone one can read them it means you can shuffle work between architects or say someone is sick or leaves the organization. PraXtice diagrams are testable which improves the quality of the architecture and reduces your risk.

But perhaps what PraXtice gives a lot of organizations for the first time is the ability to measure. You can measure the progress of the architecture. You can measure how stable the project is. Is its scope consistent or wildly variable? PraXtice is a really good to measure that. You can compare projects which will improve your estimations and resource planning. You can even use them to predict solution performance; before you build it!

And that's just what I can think of in three minutes. I guess the short answer is more control than you've ever had before, improved risk management and an ability to make some predictions. All the sought of things that good architecture should be doing and they are all basically free value adds from using PraXtice.

Adaptive Set of Integrated Diagrams. Its adaptive because you can add to it whatever you need and it's an integrated set because each diagram relates to the other diagrams. They instruct, inform and regulate the solution to ensure consistency (the best version of the truth) . The occurs in several ways.

The first and most obvious way is in the content of the diagram. But the diagrams are also part of the method and a diagram's position in the method provides context and traceability. The diagrams are often derived from previous diagrams or are tested against them this introduces a degree of rigour that is generally absent from architecture practice. The result is that diagrams can be tested and errors and omissions exposed. We're not saying it's perfect, but its next level compared with the pictures produced by most architecture groups that can't be interpreted the same way twice.

Well, simply what it does is define what is architecture. What you'll find in many organizations; particularly those with low skills in areas like Project Management, is that Solution Architects in particular have to fill in for the short comings of other disciplines. A colleague of mine refers to it as being the IT adult. It's disastrous, it takes up the Architect's time with tasks that are not architecture. It allows other team members to cop out and removes any incentive for them to improve. And so you end up in a situation where Architects are overloaded with other peoples tasks.

ArchiMate has been around for about 20 years; longer than most architects have been architects. So, it's nothing new, if you are not using ArchiMate I don't know how you can claim to be a “TOGAF” shop which practically everyone does?

Internationally it's clearly on the rise and one of the factors driving it regulation in the Finance Industry; which is what triggered its development. Increasingly organizations have to prove to the likes of ASIC that you know that their systems are accurate. Some of that overflows into Australia through international organizations imposing their standards on their Australian operations. You'll also notice that you can't pickup a serious architecture book these days without it being full of ArchiMate diagrams. The tool makers all see this too, that's why they all support ArchiMate.

Sadly in Australia we're pretty backward. But I think one of the things that is really going to drive it locally is that pretty soon you are going to start seeing Software Engineering graduates from local universities asking where the ArchiMate diagrams are! I can see that in the not too distant future that no ArchiMate will mean no job.

Ah! that's where things get really interesting. What you are aiming for is a Digital Organizational Twin. Whether or not we'll ever get there is another question. But what is going to happen without you even trying is you are going to end up withe the best current state that you've ever see. And that's because every day by working in the model all your Solution Architects are building the best version of the truth and it's way more detailed and way more current than anything you've experienced before because it's dynamic.

When you get to that point you'll see other forms of documentation wither and perish because they just can't keep up. And that's the time you can start thinking about a more holistic approach to architecture. It's time to ask what type questions will are stakeholders be asking and what do we need to know? And with that comes the concept of Information Systems Services. Not my idea straight out of TOGAF. In truth it'll be the first time some organizations have actually seriously thought about their architecture and its the start of the PraXtice assimilation activity.