Correlated Architectures

Enterprise Architecture are about visibility of information, including the processes, services, resources, data descriptions and rules and policies of government. They also describe government, how it works, its resources and services
These architectures, as an information, is often captured in different kinds of viewpoints, and most of the time as models.
Good Architectures make all the data more valuable by describing how they co-relate with other organization dimensions.
The most valuable architectures are models with a formal meta model or schema, e.g. TOGAF among others.
But currently – most models are not web data accessible, they are trapped in tools, files and worst then even images as pictures and theese odels are not linkable or linked across other models. There can be models for business processes, it portfolio management, organization structures, strategies and intents, data schemas, balance scorecards, soa interfaces...
Architecture models are just data, and as such they shall be federated, analysed, queried, linked and mashed up – data to be published.
As for information they can be unconnected, redundant and not usable outside their source.
There is the need to design and develop various tools, approaches and techniques for querying, viewing, federating and analysing the architectures of the organization as a whole, this can enable consistent visibility and collaboration, provide for external comments and input from stakeholders
Last but not least, having computable architectures, we can pretend to drive and affect the organizaitons from them, making it live, more then aligned with the business, they are the nervous system of the organization.

Spaghetti Modelling

The modelling based architectures, like MDA, MDE, MDD, enforce essentially a strong separation of concerns bewteen the business architecture and the technical architecture. By simply having models for defining the processes, the rules and the functional specification in general separated from the technicalities such as service binding, design pattern, deployment, state management ... is a great strategy to improve reuse, scalability, division of work across team, software life cycle, asset creation and so forth.
In essence, the application can be defined as a set of models; for example business processes, business entities class model, interfaces, UIs, business rules, component models, ... but this is not sufficient for a clear and neat model structure. The risk in ending with Spaghetti Modelling is still here; we will not end up with a comprehansible set of models of the application just because we are adopting a model driven approach.
Care must be taken in creating a proper model set that is comprehensible and that does not mix the various logical views. This risk can be reduced by adopting an application metamodel (call it application template if you wish) but it's not sufficient, in general there is the need for a good modelling practise that comes of course from the experience but also from the the good old motto "think before modelling" (aka "think before coding").
We will less an less write lines of programming language in the future (that is already here) but we will always abstract the problem space into a solution space, that is the same class of problem.

SQL NO, NoSQL

Yesss, finally a movement for SQL alternative for data persistence and retrieval! There 'can be' something better.
Why lumping SQL relational statements for searching data that are natively object oriented?
Why tables, inner-outer join, stored procedures, custering of relational tables? Data is to be managed in a language and approch in line with the way we manage them in memory.
Yes, we can do better then SQL and these guys have strategies, ideas and tools!
The issue is far too complex to be addressed by a Blog here, but the problem is real and new way to deal with data persistence and retrieval is here especially now with "cloud computing" and the need to manage Tera and Peta bytes. There is more then quey language and ORM (Object Relationak Mappings), RDBMS demostrate not to be able to scale, simply because the cost is exponential and the ability to spend in RDBMS clusters is not infinite.