http://ayende.comAyende @ RahienCopyright (C) Ayende Rahien 2004 - 2021 (c) 202660Bart, precisely. The next part is going to talk about hot deployment, which is part of this. http://ayende.com/2957/a-vision-of-enterprise-platform#comment7http://ayende.com/2957/a-vision-of-enterprise-platform#comment7Mon, 19 Nov 2007 17:01:13 GMTAyende, I read the following in your post: "This screen will be responsible for generating three files. /entities/Account.boo, /controllers/AccountController.boo, /views/Account/edit.brail These files represent the way the sum total of information that the system needs to know about an entity. Those are also versioned files, and more importantly, they are very malleable for user modifications." Does this mean that there is no recompilation necessary? http://ayende.com/2957/a-vision-of-enterprise-platform#comment6http://ayende.com/2957/a-vision-of-enterprise-platform#comment6Mon, 19 Nov 2007 08:28:23 GMTI guess everyone focuses on what is most familiar to them. For myself, the workflow part is interesting. I have used the proposed style before, although I have called them "transaction enlistees". For full functionality, the three things you need with them are some sort of unit-of-work (so they can participate in a transaction), a way to manage them (perhaps via the controllers), so that they are only "registered" when they need to be, and finally a way to tell what has changed (maybe your unit-of-work will do that for you). An unrelated (to workflows) warning: Scalability is not free. http://ayende.com/2957/a-vision-of-enterprise-platform#comment5http://ayende.com/2957/a-vision-of-enterprise-platform#comment5Sat, 17 Nov 2007 14:53:41 GMTSounds good to me so far... How exactly would upgrades work? Assuming you ship a core set of entities with your application and in your next version you have some small changes in the controller for an core entity. The customer also changed something in the same controller. Will the SCM server simply perform a merge operation for these updates? Or would these core entities be simply 'read only' to avoid any update problems, but of course limiting the ability to change the system. Also what about versioning of the database itself? http://ayende.com/2957/a-vision-of-enterprise-platform#comment4http://ayende.com/2957/a-vision-of-enterprise-platform#comment4Sat, 17 Nov 2007 12:18:24 GMTNice article Ayende ... it is extremely interesting for me... At the moment I am more interested in the security infrastructure that you mentioned at the end of the post. I've already built a kind of framework for user management, shared user profile and single sign-on for our internal and external applications and users using plenty authentication methods like u/p, AD, RADIUS, cryptocards, SIM challenge. Apart from basic authorization based on roles, I am planning to go further and support also advanced features like: assignable permissions, hierarchical securable resources and a combination between role-based security and permission based security. Everything is centrally administered and tasks can be delegated to lower rights power users. Disabling a user, for example, has immediate effect and the user automatically is prevented to login in any integrated applications where user had the right to access it. One of the must haves that you forgot to mention about the dream enterprise platform is the support interop and integration with existing platforms and services already in the target company. No enterprise platform, no matter how well designed and extensible is built, will exist in isolation. Large companies like the one for which I currently work use myriad of systems and technologies in running their business. Invoices and customers are considered master in the billing platform, products and services are defined in the ERP/financial system, customer interaction and events are kept in the CRM platform. Retail system, for example, sucks data from all of these platforms providing an unified environment for sales representatives. Considering all the above, not providing interop services (the lingua franca between UNIX/C, .NET/CLR, UNIX/Java) is considered as bad design and will not ever be accepted for production use. Therefore, my .NET framework has APIs for multiple platforms and can be accessed from Java, PHP, Delphi, .NET, C++ apps not matter the platform on which the member system is runing: Win32, CLR, JVM, Unix ELF etc. Could you please detail a little bit more on how do you envision the framework for data security? For example, how would you build a system which should show to managers an aggregated view of all their subordinates transactions and how team leaders will only view a vertical slice of data depending on the permissions? Where would you store metadata about these security levels? Regards, Robert http://ayende.com/2957/a-vision-of-enterprise-platform#comment3http://ayende.com/2957/a-vision-of-enterprise-platform#comment3Sat, 17 Nov 2007 11:16:56 GMTNice overview! Exactly what you need in many applications.. When shall we start building ? ;-))) http://ayende.com/2957/a-vision-of-enterprise-platform#comment2http://ayende.com/2957/a-vision-of-enterprise-platform#comment2Sat, 17 Nov 2007 08:29:03 GMTI think you are right on target. And so does Scott Hanselman based on this document. http://www.hanselman.com/blog/content/binary/Hanselman%20-%20Managing%20System%20Deployment%20with%20PowerShell.pdf Its not just about powershell but also how the entire deployment environment is under change control using subversion and where customers managed and deploy things themselves. Have you read it?I http://ayende.com/2957/a-vision-of-enterprise-platform#comment1http://ayende.com/2957/a-vision-of-enterprise-platform#comment1Sat, 17 Nov 2007 04:34:57 GMT